Linkrev perf

[Durham Goode]

On 9/30/16 8:20 AM, Jun Wu wrote:
> Suppose the repo has linear history, the only reason we need .d walk is
> because of obsoleted changesets.
I don't think we can assume the repo is linear though.  Even for a repo 
without merges, if a user performs a graft onto a release branch, that 
can result in duplicate linkrevs without any obs markers being created. 
(and at that point we can't blindly rewrite the linkrev if a future obs 
marker comes along, because we don't know what other commits have file 
nodes that use that linkrev).
>
> Consider the simple amend case, where 6 is replaced by 7:
>
>    o    7 : filerev=1
>    |
>    | x  6 : filerev=1        o  1 : linkrev=6
>    |/                        |
>    o    5 : filerev=0        o  0 : linkrev=5
>    changelog                 filelog
>
> It's obvious that if we rewrite linkrev from 6 to 7 in this case, we no
> longer need .d walk, since the new linkrev will be in the visible branch.
>
> Hence I suggest rewrite linkrev when creating an obsolete marker: if the
> linkrev was pointed to a obsoleted changeset, and one of the successor
> has a same filerev, rewrite the linkrev to the earliest successor with a
> same filerev.
Rewrite it where? In the revlog?  That sounds dangerous.  Other 
algorithms currently depend on the linkrev pointing at the earliest 
instance, so I don't think we'd want to break that invariant entirely.
>
> It could be done synchronously (rewrite immediately when a marker is being
> created) or asynchronously (cleanup in crontab), if the former is too
> expensive or has issues with transactions.