应用错误收集

我刚刚在存储库上执行了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就好了。

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

好吧，由于第一个损坏的变更集为170，您可以将本地存储库克隆为169，然后从源中取出。这意味着只需提取5个变更集。

hg clone -r 169 damagedrepo fixedrepo
cd fixedreop
hg verify

然后：

hg pull originalsource

至于手动恢复存储库损坏，this page对此进行了更好的阐述。见第4节。

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

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

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

注意：此方法将更改所有哈希值。

实际上还有另一种方法可以在存储库损坏时恢复存储库 -

您可以使用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”。

尝试从repo中删除文件00manifest.i，然后使用hg remove 00manifest.i和hg commit命令。为我工作。

我们最终做的是制作我们的“中央”存储库的新副本，删除此副本中的.hg文件夹，在那里创建一个新的存储库（hg init），然后将其作为中央存储库使用。 / p>

请注意，如果您不需要您的变更集历史记录（我们不需要），这只是一个合适的解决方案。您仍然可以使用旧的中央存储库来实现此目的。

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

4 个答案: