我们刚刚在一周前重新创build了所有的回购协议，今天我们已经接近这一点。 我需要弄清楚为什么这个事情继续发生…
$hg verify checking changesets checking manifests crosschecking files in changesets and manifests checking files smartdox/application/helpers/common_helper.php@?: rev 1 points to unexpected changeset 10 (expected ) smartdox/application/helpers/common_helper.php@?: fbe7ec6785e5 not in manifests smartdox/application/libraries/MY_Model.php@?: rev 1 points to unexpected changeset 10 (expected ) smartdox/application/libraries/MY_Model.php@?: d84e95aff93f not in manifests smartdox/application/product_customizers/Proposals - CA Integrated/product.php@?: rev 1 points to unexpected changeset 2 (expected 7) smartdox/application/product_customizers/Proposals - CA Specialty/custom.js@?: rev 1 points to unexpected changeset 2 (expected 7) smartdox/application/product_customizers/Proposals - CA Specialty/product.php@?: rev 1 points to unexpected changeset 2 (expected 7) smartdox/application/product_customizers/Proposals - GA Integrated/product.php@?: rev 1 points to unexpected changeset 2 (expected 7) smartdox/application/product_customizers/Proposals - NY Combined/custom.js@?: rev 1 points to unexpected changeset 5 (expected 10) smartdox/application/product_customizers/Proposals - NY Combined/custom.js@?: rev 2 points to unexpected changeset 6 (expected 12) smartdox/application/product_customizers/Proposals - NY Combined/product.php@?: rev 1 points to unexpected changeset 2 (expected 7) smartdox/application/views/help/training.php@?: rev 1 points to unexpected changeset 7 (expected 6) smartdox/css/admin.css@?: rev 1 points to nonexistent changeset 26 (expected ) smartdox/css/admin.css@?: 5c92b2914085 not in manifests 我知道我们需要重新创build回购，但是我需要确定问题的实际来源，所以我知道为什么会一直发生。 任何人有任何想法，我可以如何调查/解决这些问题？ https://www.mercurial-scm.org/wiki/RepositoryCorruption没有我所希望的那么有帮助…它没有概括出发生了什么变化rev x points to unexpected changeset x
看起来Mercurial应该是交易型的，因此不应该让我们损坏我们的仓库，除非我们进入并手动删除文件。
UPDATE
我们相信桑巴是问题。 我们使用它来映射Windows上的Linux驱动器，所以我们可以使用龟HG。 我们正在提出替代解决scheme。
这在正常使用中不会发生。 大多数网站都有回收多年，没有看到hg verify说一个事情。
我见过的唯一一次是由以下原因之一引起的：
find . -name '*.bak' | xargs rm find . -name '*.bak' | xargs rm find . -name '*.bak' | xargs rm 。 这似乎是非常安全的，但它删除文件从repo/.hg/store这是一个没有用户的去区 find repo -type f | xargs perl -pie 's/1999/2000' find repo -type f | xargs perl -pie 's/1999/2000' 。 这感觉就像你在工作目录中的所有文件中将1999年更改为2000年，但是再次包含repo/.hg/store ，现在你的文件已损坏 hg push, pull, and clone以外的任何机制的人hg push, pull, and clone将更改或变更集从一台机器移至另一台机器。 最后一个值得另一个名单。 任何这些都是可疑的：
hg的文件服务器（尤其是windows / smb）上的repo Mercurial作者在处理位于远程文件服务器上的存储库时很难保持正确 ，但文件服务器协议基元却不存在。 例如， hg clone创建NTFS支持的硬链接，并且在本地系统上，即使get-link-count调用大于1，get-link-count调用也会返回当前数字，但是当windows客户端在smb上查询NTFS驻留的文件时，窗口总是返回一个链接计数1，这告诉mercurial没有其他克隆正在使用该文件，所以它可以被修改，而不必先做一个副本。
我认为Mercurial已经解决了最后一个问题，但是潜在的必要性是，如果“更改”是通过除了推，拉，克隆之外的其他任何命令启动的网络线而发生的，您需要拥抱DVCS的分布式特性，并拥有真正的本地克隆。
如果你的腐败是由过于宽泛的递归命令或文件服务器废话引起的，那么这是我以前从未见过的东西。
这个线程在Mercurial邮件列表上有帮助吗？