linux - 如何开始修复存储库

Question

我们一周前刚刚重新创建了所有的 repo 协议(protocol)，今天我们已经接近那个点了。我需要弄清楚为什么这种情况一直发生...

$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 应该是事务性的，因此应该永远不允许我们破坏我们的存储库，除非我们进入并手动删除文件。

更新

我们认为 samba 是问题所在。我们用它来映射 windows 上的 linux 驱动器，这样我们就可以使用 Tortoise HG。我们正在提出替代解决方案。

Answer 1

这从不在正常使用中发生。大多数网站都有 repo 多年，但从未看到 hg verify 说一句话。

我唯一一次看到这种情况是由以下原因之一引起的:

• 人们过于激进地删除文件。例如:查找。 -名称'*.bak' | xargs rm。这看起来真的很安全，但它会删除 repo/.hg/store 中的文件，这是一个 no-user-go-zone
• 人们过于激进地修改文件。例如 find repo -type f | xargs perl -pie 's/1999/2000'。这感觉就像您将工作目录中的所有文件中的 1999 更改为 2000，但您再次包含 repo/.hg/store 现在您的文件已损坏
• 人们使用任何机制而不是hg push、pull 和clone 将变更或变更集从一台机器移动到另一台机器。

最后一个值得再列出一份 list 。任何这些都是可疑的:

• 文件服务器(尤其是 windows/smb)上的 repo，hg 在本地机器上运行
• .hg 目录的 dropbox 式同步

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

我认为最后一个已经在 Mercurial 中解决了，但潜在的必要条件是，如果“更改”通过你的网络电缆来来去去，任何命令不是推、拉、或克隆你是在自找麻烦，你需要接受 DVCS 的分布式特性并拥有一个真正的本地克隆。

如果您的损坏不是由过于广泛的递归命令或文件服务器废话引起的，那么这是我以前从未见过的。