A thought for dealing with linkrevs
durham at fb.com
Fri Sep 19 12:08:50 CDT 2014
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
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.
More information about the Mercurial-devel