Mercurial 备份包含hg repos的文件系统

是否可以使用许多Mercurial存储库（例如，文件系统上有rsync）备份文件系统，并使备份处于不一致的状态

---

存储库由ssh提供服务，并提供以下请求集：{push、pull、in、out、clone}。它没有直接应用“hg commit”（它具有已知的竞争条件）。

为什么不使用

hg clone来“备份”它呢？；-）
 简单的回答是：您可以毫无问题地复制（cp、rsync等）mercurial存储库

较长的答案是：（特别是第5节，小标题“提交变更”）

Mercurial以使任何其他进程在任何时候都可以安全地读取Mercurial存储库的顺序写出更改。如果在对存储库进行更改时将存储库复制到其他位置，您将获得一些新数据，但mercurial足够聪明，可以忽略部分写入的提交。当您将创建的副本用作mercurial存储库时，您将看到新的提交或不提交，不会出现任何损坏。
mercurial会谨慎地编写自己的文件，以保持完整性。然而，这只是针对其他Mercurial客户的诚信。Mercurial中的锁定设计允许Mercurial进程通过按以下顺序写入文件来创建新的提交：

文件日志（保存给定文件的所有修订的压缩增量）
清单（具有指向与给定变更集关联的文件日志的指针）
变更日志（具有元数据和指向变更集清单的指针）
而其他Mercurial进程将按此顺序读取文件

变更日志
显示
文件日志
因此，读取器将看不到对新文件日志数据的引用，因为changelog是在原子操作中最后更新的（重命名，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
结果是一个带有changelog的备份，该changelog指向一个清单，该清单指向一个不存在的文件日志修订版本——一个损坏的存储库。在这样的存储库上运行
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的清单引用了文件
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存储库，情况并没有那么糟。请注意，在从备份中恢复已损坏的存储库后，可能需要修复它。您丢失的变更集很可能仍在开发人员的计算机上，在您修复恢复的存储库后，开发人员可以再次推送它。这个

备份存储库的完全安全的方法当然是使用
hg clone
，但将其与常规备份策略集成起来可能并不实际。
好吧，因为这里的目标是备份包含hg repos的文件系统。我将对问题进行编辑，使其更清楚。