在Mercurial中修复失败的完整性检查？

Question

我只是hg pull在存储库上做了一些变更集.它说跑了hg update,所以我做了.不幸的是,当我这样做时,它失败并出现以下错误消息:

abort: integrity check failed on 00manifest.i:173!

当我跑步时hg verify,它告诉我有一些问题不在清单中(有一些轻微的路径模糊):

>hg verify
checking changesets
checking manifests
crosschecking files in changesets and manifests
 somewhere1/file1.aspx@172: in changeset but not in manifest
 somewhere2/file1.pdf@170: in changeset but not in manifest checking files
 file3.csproj@172: ee005cae8058 not in manifests
 somewhere2/file1.pdf@171: 00371c8b9d95 not in manifests
 somewhere3/file1.ascx@170: 5c921d9bf620 not in manifests
 somewhere4/file1.ascx@172: 23acbd0efd3a not in manifests
 somewhere5/file1.aspx@170: ce48ed795067 not in manifests
 somewhere5/file2.aspx@171: 15d13df4206f not in manifests
1328 files, 174 changesets, 3182 total revisions
8 integrity errors encountered!
(first damaged changeset appears to be 170)

源存储库传递hg verify正常.

有没有办法从完整性检查失败中恢复,或者我是否需要从源完全重新克隆存储库(在这种情况下不是一个大问题)？我能做些什么导致这种情况,所以我不再这样做了？

Answer 1

好吧,因为第一个损坏的变更集是170,你可以将你的本地存储库克隆到169,然后从源中拉出来.这意味着只需要拉动5个变更集.

hg clone -r 169 damagedrepo fixedrepo
cd fixedreop
hg verify

然后:

hg pull originalsource

至于手动恢复存储库损坏,本页面对此进行了更好的阐述.见第4节.

我曾经偶尔发现过腐败,虽然上面的文档说它通常来自用户错误,但我的实例是在带有空工作目录的可移动USB驱动器上.有时事情不能正确写入或以某种方式受到干扰:它并不总是用户错误.但我总是有多个副本,我可以放弃,所以我已经能够逃脱基本的修复.

如果部分本地克隆的简单修复和从服务器拉出不能解决问题,那么在将更改(如果有)备份到一个或多个修补程序后,您可以选择以下两个选项:

• 手动黑客攻击Mercurial的文件.
• 从服务器执行新的完整克隆.通常两者中的更容易和更快.

Answer 2

实际上还有另一种方法来恢复存储库,当它像这样被破坏 -

您可以使用convert扩展来完全重建存储库.请参阅https://www.mercurial-scm.org/wiki/RepositoryCorruption#Recovery_using_convert_extension上的第4.5节

首先通过将以下内容添加到〜/ .hgrc文件来启用转换扩展

[extensions]
convert=

然后转换坏回购以创建固定的回购:

$ hg convert --config convert.hg.ignoreerrors=True REPO REPOFIX

当我有突然发现清单中缺少文件的经历时,这对我有用 - "错误255".