Home/ Questions/Q 6087739
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-23T11:54:16+00:00

I just did hg pull on a repository and brought in some changesets. It

  • 0

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
 somewhere5/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?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.
    • 0