A thought for dealing with linkrevs

[Durham Goode]

On 9/17/14, 9:08 PM, Matt Mackall wrote:
> So I've been thinking about the linkrev problem a bit again. I've
> occasionally suggested we can deduce the possible positions of the
> missing linkrevs from the shape of the changelog graph as compared to
> the filelog graph. This turned out to be complicated so it never really
> went anywhere.
>
> I'm now tinkering with the idea of treating the linkrev as a simple
> hint: "this is one possibility, and any aliases are numerically after
> it". So if we're interested in following the history of file F from
> changeset C, we can say:
>
> - is F.linkrev an ancestor of C? great, done
> - otherwise, let's look in that vicinity for changesets touching F
>
> Since the usual case for caring about this is log -f or annotate, which
> incrementally walk back through file history, we can imagine a
> "corrector" object that knows where we're following from and can correct
> related linkrevs. We can even imagine this state being automatically
> shared as we traverse contexts, thus making fctx.linkrev() magically do
> the right thing.

I've thought about this a bit, and I think it could work for 
remotefilelog too.

One of the issues I have in remotefilelog, is that when I receive a 
changegroup, I need to immediately know which changelog revs introduce 
which filelog revs.  Right now I can only see the first changelog rev 
that produced a given filelog rev.  If we have this linkcorrector thing, 
we could do the correction on the server side and include a bundle2 part 
with 1->N (filelogrev->changelogrevs) mapping for that changegroup.  
That might be useful for non-remotefilelog cases too, for clients to 
build an early cache of corrected linkrevs.

The other linkrev issue I have in remotefilelog, is that the file 
revision blobs produced by the server include a history of that file 
revision that contains the server's linkrev'd commit.  So we assume the 
client pulls every server head, so that they are guaranteed to have 
whatever commit the server's linkrev pointed at.  If we have a 
linkcorrector, I could probably use it to resolve linkrevs when the 
client hasn't pulled everything.  I'd have to override it with my own 
implementation (since I don't actually have a filelog with linkrevs), 
but the concept should still apply.