备份包含hg repos的文件系统

Mark Drago is correct Mercurial以谨慎的方式写入自己的文件以保持完整性。但是，这仅仅是关于其他Mercurial客户端的完整性。锁定设计水银允许一个水银工艺打造的顺序写入文件的新承诺：

1. filelogs（适用于特定文件的所有版本的压缩增量）
2. 清单（具有指针回与给定的相关联的变更filelogs）
3. 更改日志（具有元数据和一个指针返回到清单的变更）

而其它水银进程将在该顺序读出的文件

1. 更改日志
2. 清单
3. filelogs

读者将因此不会看到新filelog数据的参考，因为更改日志在一个原子操作最后更新（一个重命名，这POSIX要求是原子的）。

备份程序将不知道正确的顺序读取水银文件，所以它可能前阅读filelog 它是由水银更新，然后读取它被更新清单后：

1. rsync读取.hg/store/data/foo.i
2. hg写道：.hg/store/data/foo.i
3. hg写道：.hg/store/00manifest.i
4. hg写道.hg/store/00changelog.i
5. rsync读取.hg/store/00manifest.i
6. rsync读取.hg/store/00changelog.i

结果是指向一个指向filelog修订不存在---一个清单更新日志备份腐败的存储库。在这样一个资源库运行hg verify将检测到这种情况：

checking changesets 
checking manifests 
crosschecking files in changesets and manifests 
checking files 
[email protected]: f57bae649f6e in manifests not found 
1 files, 2 changesets, 1 total revisions 
1 integrity errors encountered! 
(first damaged changeset appears to be 1) 

这告诉你，修订1的清单是指文件foo，不能被发现的修订f57bae649f6e。它可以通过使排除坏的版本1的克隆修复这种情况：

$ hg clone -r 0 . ../repo-fixed 
adding changesets 
adding manifests 
adding file changes 
added 1 changesets with 1 changes to 1 files 
updating to branch default 
1 files updated, 0 files merged, 0 files removed, 0 files unresolved 
$ cd ../repo-fixed 
$ hg verify 
checking changesets 
checking manifests 
crosschecking files in changesets and manifests 
checking files 
1 files, 1 changesets, 1 total revisions 

所以，一切的一切，如果使用一般的备份程序来备份你的Mercurial库是没有那么糟糕。请注意，从备份中恢复后，您可能必须修复损坏的存储库。丢失的变更集很可能仍然在开发人员的机器上，并且在修复恢复的存储库后，他可以再次推送它。该Mercurial wiki has more information on repairing repository corruption。

备份存储库的完全安全的方法当然是使用hg clone，但将其与一般备份策略集成可能不切实际。

为什么不用hg clone“备份”它？ ;-)

简短的回答是：您可以复制（cp，rsync等）mercurial存储库没有问题。

较长的答案是：https://www.mercurial-scm.org/wiki/Presentations?action=AttachFile&do=get&target=ols-mercurial-paper.pdf（特别是第5小节“承诺变更”的子标题）。

Mercurial会按顺序写入更改，以便任何其他进程在任何时候都可以读取mercurial存储库。如果您在对存储库进行更改时将存储库复制到某个其他位置，您将获得一些新数据，但mercurial足够聪明，可以忽略部分书面提交。当你使用你创建的副本作为mercurial仓库时，你将看到新的提交或不提交，不会有任何损坏。