How to fix integrity errors ?

Pierre-Yves David pierre-yves.david at ens-lyon.org
Thu Jun 17 21:15:49 UTC 2021


Hi M. Pertin

On 6/10/21 4:26 PM, PERTIN Francois wrote:
> We are using mercurial version 3.7.3 on a Linux server.


This version of Mercurial was released 5 years ago and is considered 
quite ancient. There have been 21 other major releases of Mercurial in 
the meantime, including multiple security releases.

I strongly encourage you to upgrade your client and server.


> At one time a user got an error while trying to push.
>
> He did it again, the error disappear and push succeed but all users 
> had to re-clone the repository from the server to be able to push again.
>

This is quite suspicious. Do you have any record of the error that user 
got while pushing? Or of the error the other people got while pushing?

When did this happened?


> Since that time, running hg verify on user repository and on server 
> repository returns the following error.
>
> myfile at 23805  <mailto:cpu/val3_nonRegression/val3_nonRegScara/usr/app/rdd3.dll at 23805>: ddb482e379a1 in manifests not found
> 21293 files, 24338 changesets, 98658 total revisions
> 1 integrity errors encountered!
> (first damaged changeset appears to be 23805)

So it looks like a corruption was pushed to you repository, the revision 
of a given file is referenced in the history but is missing from the 
storage for that file. Have you kept backups of the users' repositories 
at the time of the error?

Does revision `23805` (number to use on the same repository you used to 
run verify) have any children?


> This is not an issue for all the users except for fisheye.
>
> It is not able to index the repository, it always restart after the 
> following error.
>
> Atlasian ask us to fix the server repository by using the method 
> described here: RepositoryCorruption - Mercurial 
> <https://urldefense.com/v3/__https:/www.mercurial-scm.org/wiki/RepositoryCorruption__;!!PxtyCg5I!G2l-3QNOufA29psGGqSMt4sgqbUUA6rP_CwMmyGjzx3Q-2mhJ0nxW66if53H5_0A$>
>
> I spend a lot of time trying to fix this without success.\
>
>
> Does any one know how to fix this issue?
>

It looks like Fisheye is trying to load the entire history into its own 
database and is chocking on the specific revision that contains the 
corruption. That file revision is corrupted so you will never be able to 
restore it as is. However they are multiple options to get out of this 
situation:

1) remove the changeset with the corruption from the repository (if it 
is an unused head), or rewrite the dependant history,
2) find an un-corrupted version of that file in some backup,
3) use "censors" to mark the content of that revision non-accessible 
(might need some development to the mercurial code-base),
4) convince Fisheye to be less picky.


I don't know which of the above options are actually possible in your 
case. And I don't know which one will be the best. However we can 
probably get to a solution with some email roundtrips. Can you please 
have a look at the question I wrote earlier in this email?

Cheers,

-- 

Pierre-Yves David




More information about the Mercurial-devel mailing list