To elaborate on this answer, you can use `hg debugindex -c` to print a table listing revisions and their offsets and lengths in the changelog. The offset listed will be the offset within the 00changelog.d file of the revision's data. You can verify the offsets are correct by using hexdump. e.g. if the offset is "32531" and the length is "178," use `hexdump -C -s 32531 -n 178 .hg/store/00changelog.d` to show the data for that revision. The first byte should be an 'x' (0x78) (zlib compressed) or a 'u' (0x75) (uncompressed). As for the 00changelog.i file, assuming you have a 00changelog.d file, each entry is 64 bytes. So multiply to find the offset where the "bad" revision begins.
On Tue, Nov 22, 2016 at 12:11 PM, Ryan McElroy <[email protected]> wrote: > > > On 11/22/16 7:39 AM, Jensen, Aaron wrote: > > Yesterday, a few of our developers started seeing an “abort: > 00manifest.i@60300915ca73: unknown parent!” error when running `hg pull` > (Mercurial 3.8.4 on Windows 7 x74). I tracked the problem to a specific > changeset, stripped it from our central repository, and they were able to > pull again. > > > > Last week, our Mercurial server died mid-transaction. It is very large > (over 9GB with 175k changesets). The only way to recover was to re-clone > the repository, omitting the last 9,000 commits. After the clone, I then > pushed the “missing” 9,000 changesets from an uncorrupted clone. > > > > All changesets pushed fine except for two. When I push them, I get “abort: > 00manifest.i@8ed639f6a6e0: no node!” and “abort: 00manifest.i@60300915ca73: > no node!” errors.(This second one is the same missing changeset from > above). Wjhen I tried to strip these two changesets from my repository, I > get the “abort: 00manifest.i@60300915ca73: no node!” error. I have no > idea of the missing parent/node errors are related to the corruption and > clean-up process. > > > > From the repository corruption page, it seems like my only option is to > re-clone my repository, excluding these two changesets, then pull in the > remaining changesets from an uncorrupted repository. Since our repository > takes hours to re-clone, I’m wondering if there are any other magic tricks > for stripping these two changesets from my repository. > > > > There is some magic, you can actually truncate revlog files (because they > are append-only) to get rid of the highest rev numbers. > > If you do this to just the changelog.d and changelog.i files, then I think > hg recover knows how to fix up the rest of the files in your repo. You will > lose bookmarks pointing to any changesets that you remove as well when the > bookmarks file is next written. > > _______________________________________________ > Mercurial mailing > [email protected]https://urldefense.proofpoint.com/v2/url?u=https-3A__www.mercurial-2Dscm.org_mailman_listinfo_mercurial&d=DgIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=Jw8rundaE7TbmqBYd1txIQ&m=V76LObHNHRnSJQK03fXRbq1DKsYNcQ30gQWuEPvGcLI&s=S77kHxd5m35N7u5Gz0MF6WjXIxia-HbQJgpPsQRhRtw&e= > > > > _______________________________________________ > Mercurial mailing list > [email protected] > https://www.mercurial-scm.org/mailman/listinfo/mercurial > >
_______________________________________________ Mercurial mailing list [email protected] https://www.mercurial-scm.org/mailman/listinfo/mercurial
