Hello Mr David, Thank you for your explanation. We fixed our repo by applying the following procedure and fisheye get back to work.
b) there was only one revision but the entire revlog is missing In most cases, you simply copy the revlog from .hg/store/data in another clone, but if you don't have any intact clones, then things are more difficult. If you had a single missing file revision (case b) and you have the -exact- file somewhere, you can do a hack like this: hg clone myrepo myrepo-backup hg clone -r 530 myrepo myrepo-hack # we need the next commit to be 531 cp myfile myrepo-hack/ hg add myfile hg ci -m "A new 531" Best regards. Francois PERTIN Embeded software team leader STAUBLI FAVERGES Place Robert Staubli CS 30070 74210 Faverges-Seythenex / FR Phone: +33 4 50 65 62 59 Mobile: mailto: f.per...@staubli.com www.staubli.com This e-mail and any attachment (the 'message') are confidential and privileged and intended solely for the person or the entity to which it is addressed. If you have received it in error, please advise the sender by return e-mail and delete it immediately. Any use not in accordance with its purpose, any dissemination or reproduction, either whole or partial, by entities other than the intended recipient is strictly prohibited. -----Message d'origine----- De : Pierre-Yves David <pierre-yves.da...@ens-lyon.org> Envoyé : jeudi 17 juin 2021 23:16 À : PERTIN Francois <f.per...@staubli.com>; mercurial-devel@mercurial-scm.org Objet : Re: How to fix integrity errors ? This Message Is From an External Sender This message came from outside your organization. ______________________________________________________________________ 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@23805 > <mailto:cpu/val3_nonRegression/val3_nonRegScara/usr/app/rdd3.dll@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 _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
