是否可以备份具有许多Mercurial存储库的文件系统（例如，在文件系统上使用rsync）并使备份处于不一致状态？
存储库由ssh提供并提供这组请求：{push，pull，in，out，clone}。它没有直接应用'hg commit'（具有已知的竞争条件）。
答案 0 :(得分：3)
Mark Drago is correct Mercurial谨慎编写自己的文件以保持完整性。但是，这只是与其他 Mercurial 客户端相关的完整性。 Mercurial中的锁定设计允许一个Mercurial进程通过按以下顺序编写文件来创建新提交：
而其他Mercurial进程将按此顺序读取文件
因此，读者将看不到对新文件日志数据的引用，因为更改日志最后在原子操作中更新（重命名，POSIX需要是原子的）。
备份程序无法知道读取Mercurial文件的正确顺序，因此在Mercurial更新之前它可能会读取文件日志，然后在之后读取清单它已更新：
rsync读取.hg/store/data/foo.i hg撰写.hg/store/data/foo.i hg撰写.hg/store/00manifest.i hg撰写.hg/store/00changelog.i rsync读取.hg/store/00manifest.i rsync读取.hg/store/00changelog.i 结果是带有更改日志的备份，该更新日志指向指向不存在的文件日志修订的清单---损坏的存储库。在这样的存储库上运行hg verify将检测到这种情况：
checking changesets
checking manifests
crosschecking files in changesets and manifests
checking files
foo@1: f57bae649f6e in manifests not found
1 files, 2 changesets, 1 total revisions
1 integrity errors encountered!
(first damaged changeset appears to be 1)
这告诉您修订版1的清单引用了文件f57bae649f6e的修订版foo，该文件无法找到。可以通过制作排除错误修订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，但将其与常规备份策略集成可能不切实际。
答案 1 :(得分：0)
为什么不用hg clone“备份”它？ ; - ）
答案 2 :(得分：0)
简短的回答是：您可以毫无问题地复制（cp，rsync等）mercurial存储库。
更长的答案是：https://www.mercurial-scm.org/wiki/Presentations?action=AttachFile&do=get&target=ols-mercurial-paper.pdf（特别是第5节，子标题“提交更改”）。
Mercurial在订单中写出更改，以便任何其他进程随时读取mercurial存储库。如果在对存储库进行更改时将存储库复制到其他位置，您将获得一些新数据，但是mercurial足够聪明，可以忽略部分写入的提交。当您使用您作为mercurial存储库创建的副本时，您将看到新的提交，否则不会有任何损坏。