如何开始修复存储库
我们一周前刚刚重新创建了所有存储库，今天我们已经接近这一点。我需要弄清楚为什么这种情况不断发生...
$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 指向意外变更集 x 发生的情况
似乎 Mercurial 应该是事务性的，因此永远不应该允许我们除非我们进入并手动删除文件，否则会损坏我们的存储库。
更新
我们认为 samba 是问题所在。我们用它在 Windows 上映射 Linux 驱动器，这样我们就可以使用 Tortoise HG。我们正在寻找替代解决方案。
We just recreated all of our repos a week ago and today we're already near that point. I need to figure out why this keeps happening...
$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
I know we need to recreate the repo, but I need to determine the actual source of the problem so I know why this keeps happening. Anyone have any thoughts on how I can investigate/fix these issues? https://www.mercurial-scm.org/wiki/RepositoryCorruption isn't as helpful as I would've hoped... it doesn't outline what's going on with rev x points to unexpected changeset x
It seems like Mercurial should be transactional and thus should never allow us to corrupt our repositories unless we go in and manually delete files.
UPDATE
We believe that samba is the problem. We use it to map linux drives on windows so we can use Tortoise HG. We're in the process of coming up with alternative solutions.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在正常使用中永远不会发生这种情况。大多数网站都有存储库多年，但从未见过
hg verify说什么。我唯一一次看到这种情况是由以下原因之一引起的：
查找 . -名称 '*.bak' | xargs rm。这看起来确实很安全，但它会从repo/.hg/store中删除文件，这是一个无用户区域，find repo -type f | xargs perl -pie 's/1999/2000'。感觉就像您将工作目录中的所有文件中的 1999 更改为 2000，但您再次包含了repo/.hg/store，现在您的文件已hg push、pull 和clone之外的机制，将更改或更改集从一台计算机移动到另一台计算机。最后一个值得再列出来。其中任何一个都是可疑的：
hgMercurial 作者非常努力地保持事物当您对远程文件服务器上的存储库进行操作时，这是正确的，但文件服务器协议原语不存在。例如，
hg clone创建 NTFS 支持的硬链接，在本地系统上，get-link-count 调用会返回当前数字，即使它大于 1，但当 Windows 客户端查询 NTFS-通过 smb 托管文件某些版本的 Windows 始终返回链接计数 1，这告诉 Mercurial 没有其他克隆正在使用该文件，因此无需先制作副本即可对其进行修改。我认为最后一个问题已在 Mercurial 中得到解决，但根本的要求是，如果“更改”通过除推、拉或克隆以外的任何命令启动并通过您的网络电缆进行这是自找麻烦，您需要接受 DVCS 的分布式特性并拥有一个真正的本地克隆。
如果您的损坏既不是由过于广泛的递归命令引起的，也不是由文件服务器的废话引起的，那么这是我以前从未见过的。
This never happens in normal usage. Most sites have repos for years without ever seeing
hg verifysay a thing.The only times I've seen this has been caused by one of:
find . -name '*.bak' | xargs rm. That seems really safe, but it deletes files from down inrepo/.hg/storewhich is a no-user-go-zonefind repo -type f | xargs perl -pie 's/1999/2000'. That feels like you're changing 1999 to 2000 in all files in the working directory, but again you includedrepo/.hg/storeand now your files are corrupthg push, pull, and cloneto move changes or changesets from one machine to another.That last is worth another list. Any of these are suspect:
hgrun on local machinesThe Mercurial authors work really hard to keep things correct when you're acting on a repository that's on a remote file server, but the file server protocols primitives just aren't there. For example,
hg clonecreates hard links, which NTFS supports, and on local systems the get-link-count call returns the current number even if it's greater than 1, but when windows clients are querying NTFS-hosted files over smb some versions of windows always return a link count of 1, which tells mercurial no other clone is using that file, so it can be modified without first making a copy.I think that last one has been worked around in Mercurial, but the underlying imperative is that if "changes" are coming and going over your network cable initiated by any command other than push, pull, or clone you're asking for trouble, and you need to embrace the distributed nature of DVCS and have a truly local clone.
If your corruption is caused by neither overly-broad recursive commands nor file server nonsense, then it's something I've not previously seen.
Mercurial 邮件列表上的此主题是否有帮助？
would this thread on the Mercurial mailing list help?