Mercurial: "no match found" when performing merge, "no node!" if I try to strip

Question

I have a mercurial dropbox hosted in a Dropbox folder on which I push from another repo that I keep in my office PC. In this way I can work on my project from the office and perform hotfixes from home.

Something bad happened while synchronizing, therefore a file wasn't correctly put in sync somewhere. I have a revision (n. 678) which I can't merge with actual head.

If I try to merge I get this message

abort: data/hotelsclick/src/main/res/values/string-array.xml.i@5f2b6faa86a1: no match found!

if I try to delete that useless revision with hg strip 678 I get

abort: data/hotelsclick/src/main/res/values/string-array.xml.i@5f2b6faa86a1: no node!

and if I perform a hg verify this is the result

checking files  [...]/src/main/res/values/string-array.xml@678: 5f2b6faa86a1 in manifests not found 

libs/date-interval-picker/.git/index@678: a83e1b77d446 in manifests not found 8009 files, 681 changesets, 14161 total revisions 2 integrity errors encountered! (first damaged changeset appears to be 678)

what if I try to push?

searching for changes abort: push creates new remote head 16c4912af9a5! (merge or see "hg help push" for details about pushing new heads)

So I cannot merge, cannot delete that revision, cannot push. I'm pretty stuck and I don't know why. Can anybody please help? I don't care about the content of revision 678, if I could I'd delete it happily.

Answer 1

First of all, I strongly recommend against using a file synchronization service (whether Dropbox or Google Drive or something else) for use with version control systems. These services do not respect the atomicity of repository operations; even version control systems with single file repositories (such as Fossil) are not 100% safe and even if only a single user is using the service.

Second, you have a partially corrupted repository that you need to repair. In the ideal case, you have a clean backup somewhere, even if it's not perfectly up-to-date and can replay the missing revisions selectively (e.g. with hg export and hg import).

Barring that, the next step would be to see if you can do a partial clone. For example, you can try:

hg clone -r 680 /path/to/repo /path/to/clean_repo

This should normally skip revision 678, if only that data is defective. However, the way that delta compression works, revisions that occur in order after 678 may also have been corrupted. In this case, I would try it with -r 677 instead of -r 680 and see if hg export works for copying revisions 679 and 680.

If that does not work and the corruption goes deeper, I would then try the convert extension:

hg --config extensions.convert= convert --config convert.hg.ignoreerrors=True /path/to/repo /path/to/clean_repo

Note that such a conversion will likely change the hash values of individual repository entries and means that you will have to update the repository contents everywhere.