Hello, That's what I ended up doing. At the moment I'm thinking of making a local backup (cron job every hour) of my repository using pull. Should my repo become corrupted, I will simply go back to that backup (hg will stop working and not pull in my broken changes) and be up and running quickly.
Thanks for your reponse! > On Sep 14, 2016, at 2:40 AM, Steve - Gadget Barnes <gadgetst...@hotmail.com> > wrote: > > > >> On 14/09/2016 02:48, Yves S. Garret wrote: >> Hello, >> >> I'm just setting things up. I don't care too much if I lose the history >> of what I did (since I'm just getting the ball rolling.) I've looked >> online to try to fix a corrupt repo problem >> [https://www.mercurial-scm.org/wiki/RepositoryCorruption#Repository_corruption], >> but could not resolve my problem successfully. Below is what I see when >> I try to run hg status and hg verify. >> >> I was committing some source files, but wanted to remove the generated >> binaries (*.o and *.exe), and did things such as: rm $(find . -name >> "*.o") and rm $(find . -name "*.exe") >> >> What am I doing wrong in terms of fixing my corruption problem? >> >> >> ------------------------------------------------ >>> hg status >> abort: data/.hgignore.i@c5b3783f0f50: no match found! >>> hg verify >> checking changesets >> checking manifests >> crosschecking files in changesets and manifests >> checking files >> warning: revlog 'data/.hgignore.i' not in fncache! >> 1: empty or missing .hgignore >> .hgignore@1: manifest refers to unknown revision 602c3078f3a7 >> .hgignore@29: manifest refers to unknown revision 686c69daad40 >> .hgignore@31: manifest refers to unknown revision c034338208d6 >> .hgignore@32: manifest refers to unknown revision f8093b62cdbb >> .hgignore@34: manifest refers to unknown revision c5b3783f0f50 >> warning: revlog 'data/mercurial_specific/.hgrc.i' not in fncache! >> 2: empty or missing mercurial_specific/.hgrc >> mercurial_specific/.hgrc@2: manifest refers to unknown revision >> 8369752b7b5e >> 183 files, 60 changesets, 183 total revisions >> 2 warnings encountered! >> hint: run "hg debugrebuildfncache" to recover from corrupt fncache >> 8 integrity errors encountered! >> (first damaged changeset appears to be 1) >> >> >> _______________________________________________ >> Mercurial mailing list >> Mercurial@mercurial-scm.org >> https://www.mercurial-scm.org/mailman/listinfo/mercurial > > Yves, > > First how you got your problem, rm (find...) will remove, normally > hidden, items that hg uses for its own housekeeping so basically don't > do it. Whenever you are operating within any DVCS repository such tools > need to be told not to enter the special, invisible, directories such as > .hg or you are likely to get the same problem again. > > To recover, since you are not too worried about the history at this > point, if you have not yet pushed your repository just move to a new > directory, initialise it and then add your source code - remembering to > set up the ignores for *.o* & *.exe files, build directories, etc. If > you have already pushed anything then clone your repository to a new > folder, add your changes so far, set up your ignores, (and if necessary > us hg rm for any binaries), and then re-commit. If your pushed > repository is in too much of a mess, e.g. lots of binaries, you can > clone it to a fresh directory, tidy it up or clone the significant parts > to a new one, check it and then request that the original be deleted. > > Hope this is some help. > > -- > Steve (Gadget) Barnes > Any opinions in this message are my personal opinions and do not reflect > those of my employer. > _______________________________________________ > Mercurial mailing list > Mercurial@mercurial-scm.org > https://www.mercurial-scm.org/mailman/listinfo/mercurial _______________________________________________ Mercurial mailing list Mercurial@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial
