开发者

Fixing a failed integrity check in Mercurial?

I just did hg pull on a repository and brought in some changesets. It said to run hg update, so I did. Unfortunately, when I did that, it failed with the following error message:

abort: integrity check failed on 00manifest.i:173!

When I run hg verify, it tells me there are a number of issues with things not in the manifest (with some slight path obscuring):

>hg verify
checking changesets
checking manifests
crosschecking files in changesets and manifests
 somewhere1/file1.aspx@172: in changeset but not in manifest
 somewhere2/file1.pdf@170: in changeset but not in manifest checking files
 file3.csproj@172: ee005cae8058 not in manifests
 somewhere2/file1.pdf@171: 00371c8b9d95 not in manifests
 somewhere3/file1.ascx@170: 5c921d9bf620 not in manifests
 somewhere4/file1.ascx@172: 23acbd0efd3a not in manifests
 somewhere5/file1.aspx@170: ce48ed795067 not in manifests
 somewhe开发者_开发知识库re5/file2.aspx@171: 15d13df4206f not in manifests
1328 files, 174 changesets, 3182 total revisions
8 integrity errors encountered!
(first damaged changeset appears to be 170)

The source repository passes hg verify just fine.

Is there any way to recover from an integrity check failure or do I need to re-clone the repository completely from the source (not a huge issue in this case)? What could I have done to cause this, so I don't do it again?


Well, since the first damaged changeset is 170, you could clone your local repository to 169 and then pull from the source. That means only pulling 5 changesets.

hg clone -r 169 damagedrepo fixedrepo
cd fixedreop
hg verify

And then:

hg pull originalsource

As for manual recovery of repository corruption, this page expounds on that better than I can. See section 4:

I have found corruption once in a while before, and although the above documentation says it is usually from user error, my instances were on removable USB drives with empty working directories. Sometimes things just don't get written correctly or are interfered with somehow: it's not always user error. But I always have multiple copies I can reclone from so I've been able to get away with basic fixing.

If the simple fix of a partial local clone and pulling from the server doesn't fix it, you're down to 2 options after backing up your changes (if any) to a bundle or patches:

  • Manually hacking at Mercurial's files.
  • Doing a new full clone from the server. Usually the easier and faster of the two.


Beware: This method will change all hashes.


Actually there is another way to recover the repository when it is corrupted like this -

You can do a complete rebuild of the repository by using the convert extension. See Section 4.5 on https://www.mercurial-scm.org/wiki/RepositoryCorruption#Recovery_using_convert_extension

First enable the convert extension by adding the following to your ~/.hgrc file

[extensions]
convert=

Then convert the bad repo to create a fixed repo:

$ hg convert --config convert.hg.ignoreerrors=True REPO REPOFIX

This worked for me when I had the experience of suddenly finding that there were missing files in the manifests - "error 255".


Try remove your file 00manifest.i from repo and next use hg remove 00manifest.i and hg commit commands. Worked for me.


What we ended up doing was making a new copy of our 'central' repository, deleting the .hg folder in this copy, creating a new repository there (hg init), and then working with this as the central repository.

Be aware however this is only an appropriate solution if you don't need your changeset history other than as a reference (which we don't). You can still use your old central repository for this purpose.

0

上一篇:

下一篇:

精彩评论

暂无评论...
验证码 换一张
取 消

最新问答

问答排行榜