linux - 如何开始修复存储库

我们刚刚在一周前重建了所有的回购，今天我们已经接近那一点了。我需要弄清楚为什么会这种情况继续发生......

$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

我知道我们需要重新创建回购，但我需要确定问题的实际来源，所以我知道为什么会这样。有人对我如何调查/解决这些问题有任何想法？ https://www.mercurial-scm.org/wiki/RepositoryCorruption并没有像我希望的那样有用......它没有概述rev x points to unexpected changeset x

的内容

似乎Mercurial应该是事务性的，因此绝不允许我们破坏我们的存储库，除非我们进入并手动删除文件。

更新

我们认为桑巴舞是个问题。我们使用它来映射Windows上的Linux驱动器，以便我们可以使用Tortoise HG。我们正在提出替代解决方案。

此从不在正常使用情况下发生。大多数网站都有回收多年而没有看到hg verify说出一件事。

我见过的唯一一次是由以下其中一个引起的：

人们过于积极地删除文件。例如：find . -name '*.bak' | xargs rm。这似乎非常安全，但它会删除repo/.hg/store中的文件，这是一个无用户区域
人们过于积极地修改文件。例如find repo -type f | xargs perl -pie 's/1999/2000'。感觉就像你在工作目录中的所有文件中将1999更改为2000，但是再次包括repo/.hg/store，现在你的文件已损坏
使用hg push, pull, and clone以外的任何机制将人们的更改或更改集从一台计算机移动到另一台计算机。

最后一个值得另一个清单。其中任何一个都是可疑的：

在本地计算机上运行hg的文件服务器（尤其是windows / smb）上的repo
.hg目录的dropbox风格同步

当您在远程文件服务器上的存储库上操作时，Mercurial作者非常难以保持正确，但文件服务器协议原语并不存在。例如，hg clone创建NTFS支持的硬链接，在本地系统上，get-link-count调用返回当前数字，即使它大于1，但是当Windows客户端通过smb查询NTFS主机文件时某些版本的Windows总是返回1的链接数，这告诉mercurial没有其他克隆正在使用该文件，因此可以在不先复制的情况下对其进行修改。

我认为最后一个已经在Mercurial中解决了，但潜在的必要性是，如果“更改”正在通过任何命令启动的网络电缆进行，而不是推，拉，或克隆你要求麻烦，你需要拥抱DVCS的分布式特性并拥有一个真正的本地克隆。

如果您的损坏既不是由过于宽泛的递归命令引起的，也不是文件服务器无意义引起的，那么这是我以前没见过的。

会在Mercurial邮件列表帮助上this线程吗？

如何开始修复存储库

2 个答案: