我希望我能在这里得到一些帮助，因为SO UX比Mercurial邮件列表更好。
多年来，我一直在家里快乐地使用Mercurial。我还在Bitbucket Cloud中使用了它，进行了一些更严重（但仍然很有趣）的项目。
去年，我将工作团队从SVN（托管公司）转移到Hg（自行托管，并在网络位置建立了中央仓库）。我们都在Windows中。从那以后，我们一直在遇到严重的中央存储库损坏的问题，这些问题只能通过备份来解决，例如：
% hg verify --verbose
repository uses revlog format 1
checking changesets
checking manifests
manifest@92: unknown parent 1 ef0f96d78ab6 of ef0f96d78ab6
manifest@92: reading delta ef0f96d78ab6: integrity check failed on
00manifest.i:88
manifest@93: unknown parent 1 e336adb3580b of e336adb3580b
manifest@93: reading delta e336adb3580b: integrity check failed on 00manifest.i:89
manifest@94: reading delta 7243aebd542b: unknown compression type '\x08'
manifest@95: reading delta 899e4507ca01: unpack requires a string argument of length 12
manifest@96: reading delta 12d4d930da4f: Manifest had an entry with a zero-length filename.
...
Some people say由于锁定问题，我们不应将网络共享用于中央存储库。 Others解释说Mercurial不使用这些锁，除非文件系统有问题，否则网络共享应该可以正常工作。
考虑到后者，我想知道是否可以以某种方式调试我们的安装而不要求公司为hg提供服务器。我对所使用的配置了解不多，但这就是我所看到的。可通过Windows网络路径\\domain.com\path\path\our-directory访问该目录。在内部，我们创建了一个名为root的目录，其中存放.hg。在.hgrc中，路径相应为
[路径]
默认= \\ domain.com \ path \ path \我们的目录\ root
我们的网络目录已由公司备份。汞版本为4.9。
答案 0 :(得分：0)
我在类似的设置上也有类似的经历。
首先要注意的是，我认为较旧的HG版本在Windows网络文件共享上运行时确实确实存在一些问题，因此请确保您的版本是最新的。 （那是几年前的IIRC，所以这不太可能成为您当前问题的根本原因）。
第二，在我的情况下，这些问题似乎是由于在虚拟机中从运行HG造成的。相反，我现在在未虚拟化的PC上运行一个[hg serve][1]实例，并使用各种HG客户端运行该实例。没问题了。
看来，如果运行hg serve的PC和文件服务器之间的连接比我作为客户端运行的服务器更可靠，则可以避免此问题。显然，hg serve用于客户端的HTTP连接本身更加可靠。
我不能说这是一个确定的解决方案，因为我从未找到根本原因。但这似乎已经避免了很长时间的腐败。
请注意，hg serve是内置在标准hg命令行工具中的，您可以在任何地方轻松运行它，而不必在存储物理存储库的同一服务器上运行。因此，就我而言，我很随意地使用它。 （显然）如果您需要更强大的功能，则可能需要与IT人员进行协调。