linkrev corruption (was Re: Corrupted repo? Full of unexpected changesets)

[Jun Wu]

Excerpts from Martin von Zweigbergk's message of 2017-10-29 22:46:25 +0000:
> I think Jun (on CC) once wrote some extension that would cache linkrevs. I
> think it could be configured not to care about the linkrevs in the revlog
> at all. If that's correct, it seems like one could run a server with that
> config and it would produce a correct clone.
> 
> Jun, do I remember the right?

Sorry for the slow response. linkrevcache [1] recalculates linkrevs from
scratch and in theory works in this linkrev corruption case regardless of
what config options are used.

The extension was initially built for server-side usecase. So its interface 
is a bit low-level and it is not "strip-friendly":

  hg debugbuildlinkrevcache --end REV

If you know the max number of corruption rev, pass that to the command and
it would probably "fix" your repo. Note that if you strip rev < REV in the
repo by running strip, amend, rebase, histedit without obsstore enabled, or
rebase --abort, histedit --abort with obsstore enabled, the cache needs to
be rebuilt manually.

[1]: https://bitbucket.org/facebook/hg-experimental/src/39a1cf89e6a24441ac7d68615b206d4f9ee63257/hgext3rd/linkrevcache.py
> 
> On Sun, Oct 29, 2017, 15:37 Augie Fackler <raf at durin42.com> wrote:
> 
> >
> > > On Oct 28, 2017, at 9:23 PM, Kim Alvefur <zash at zash.se> wrote:
> > >
> > > Hi,
> > >
> > > I've got a repo that, when running `hg verify`, produces a number of
> > > messages like:
> > >
> > >> rev 42 points to unexpected changeset 6074
> > >
> > > A tarball of the repo can be downloaded from
> > > <https://www.zash.se/upload/unexpected-changesets.tar.gz
> > >
> > > It's a clone of <https://hg.prosody.im/timber/
> > >
> > > I'm not entirely sure what I have done to it. `hg debugupgraderepo` may
> > > have been involved, as well as hardlinking to other repos.
> > >
> > > Oddly enough, the problem appears to follow along when it is cloned.
> >
> > I’ve known about problems like this for a while - in fact, for a long time
> > the way to fix them was to push them to code.google.com and then clone
> > back out, as the nature of Google’s custom hg server meant it scrubbed
> > these problems away.
> >
> > I suppose for an “easy” fix we could add some sort of debug config setting
> > that would re-guess linkrevs on the way in - it’d be *really* slow on large
> > repos, but would work.
> >
> > > I don't consider recovery of this particulary important, I'm more
> > > interested in knowing how this could have happened and, if this can be
> > > traced down no a bug in hg, seeing that fixed.
> >
> > It’d be interesting to know if you can reproduce this with `hg
> > debugupgraderepo`: if you can, please file a bug.
> >
> > This corruption is partially harmless - it can result in pushes omitting
> > file contents in such a way that the server has a broken history (which is
> > how I discovered the problem.) We should probably figure out a way to fix
> > it, especially now that GCode is gone.
> >
> > AF
> >
> > >
> > > --
> > > Regards,
> > > Kim "Zash" Alvefur
> > > _______________________________________________
> > > Mercurial-devel mailing list
> > > Mercurial-devel at mercurial-scm.org
> > > https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
> >
> > _______________________________________________
> > Mercurial-devel mailing list
> > Mercurial-devel at mercurial-scm.org
> > https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
> >