Data corruption of a mercurial repository

Question

I have a mercurial repository at c:\Dropbox\code. I've created a clone of this repo locally using:

hg clone -U c:\Dropbox\code c:\GoogleDrive\codeBackup

This bare repo serves the purpose of backup only. I regularly push changes to codeBackup. Furthermore, both the directories are backed-up in the cloud (Dropbox & Google Drive respectively).

If my repo in code becomes corrupt would the codeBackup repo automatically be corrupt since the clone operation used hard links to the original repo? Thus my double-cloud-backup strategy would be useless?

P.S. : I understand that the fall back option is to use the cloud service to restore a previous known good state.

---

UPDATE : After digging around, I'll add these for reference

• Discussion on repo corruption in mercurial

The problem is, if a 'hg clone' was done (without --pull option), then the destination and the source repo share files inside .hg/store by using hardlinks 1, if the filesystem provides the hardlinking feature (NTFS does).

Mercurial is designed to break such hardlinks inside .hg if a commit or push is done to one of the clones. The prerequisite for this is, that the Windows API mercurial is using should give a correct answer, if mercurial is asking "how many hardlinks are on this file?".

We found out that this answer is almost always wrong (always reporting 1, even if it is in fact >1) iff the hg process is running on one Windows computer and the repository files are on a network share on a different Windows computer.

• To avoid hardlinks (use --pull):

  hg clone -U --pull c:\Dropbox\code c:\GoogleDrive\codeBackup

• To check for hardlinks:

  fsutil hardlink list <file> : Shows all hardlinks for <file>

  find . -links +1 : Shows all files with hardlinks > 1

  ls -l : shows hardlinks count next to each file

Answer 1

The only way you code repository can become corrupt (assuming it was not corrupt when you initially cloned it over to codeBackup) is when you write something to it, be it committing, rewriting history, etc. Whenever something gets written to a hard-linked file, Mercurial first breaks the hard link, creates an independent copy of the file and then only modifies that newly created copy.

So to answer your questions: under normal usage scenarios repository corruption will not propagate to your codeBackup repository.

Answer 2

The biggest problem here, regarding repository corruption, is that you're using Dropbox and Google Drive to synchronize repositories across machines.

Don't do that!

This will surely lead to repository corruption unless you can guarantee that:

1. Your machines will never lose internet connection
2. You will never have new changes unsynchronized on more than one machine at a time (including times where you have had internet problems)
3. That Dropbox will always run (variant of never lose internet connection)
4. You're not just plain unlucky regarding timing

To verify that Dropbox can easily lead to repository corruption, do the following:

1. Navigate to a folder inside your Dropbox or Google Drive folder and create a Mercurial repository here. Do this on one machine, let's call this machine A.
2. Add 3 text files to it, with some content (not empty), and commit those 3 text files.
3. Wait for Dropbox/Google Drive to synchronize all those files onto your second computer, let's call this machine B
4. Either disconnect the internet on one of the machines, or stop Dropbox/Google Drive on it (doesn't matter which one)
5. On Machine A, change file 1 and 2, by adding or modifying content in them. On Machine B, change file 2 and 3, making sure to add/modify in some different content from what you did on machine A. Commit all the changes on both machines.
6. Reconnect to the internet or restart Dropbox/Google Drive, depending on what you did in step 4
7. Wait for synchronization to complete (Dropbox will show a green checkmark in its tray icon, unsure what Google Drive will display)
8. Run hg verify in the repositories on both machine A and B

Notice that they are now both corrupt:

D:\Dropbox\Temp\repotest>hg verify
checking changesets
checking manifests
crosschecking files in changesets and manifests
checking files
 3.txt@?: rev 1 points to unexpected changeset 1
 (expected 0)
 3.txt@?: 89ab3388d4d1 not in manifests
3 files, 2 changesets, 6 total revisions
1 warnings encountered!
2 integrity errors encountered!

Instead get a free bitbucket or kiln account and use that to push and pull between to synchronize across multiple computers.