Question

这是我在hg验证时得到的结果：

repository uses revlog format 1
checking changesets
checking manifests
crosschecking files in changesets and manifests
checking files
 includes/base/class/ViewInstanceAdapter.class.php@7: broken revlog! (index data/includes/base/class/ViewInstanceAdapter.class.php.i is corrupted)
warning: orphan revlog 'data/includes/base/class/ViewInstanceAdapter.class.php.i'
158 files, 61 changesets, 270 total revisions
1 warnings encountered!
1 integrity errors encountered!
(first damaged changeset appears to be 7)

我长时间不使用Mercurial，我不明白这意味着什么。

（我在使用TortoiseHg的Windows上，项目只在本地）

Answer 1

如前所述（尽管您已经确认这不起作用），您应该首先尝试克隆存储库;如果问题与dirstate有关，这可以绕过它。

接下来，每个克隆都包含一个完整的存储库，因此每个克隆实际上都是一个备份。你没有中央服务器或同事或其他本地副本吗？尝试克隆，然后从损坏的存储库中提取。由于第一个损坏的变更集被报告为否。 7（在270中），这应该是一个非常古老的，因此很容易恢复，并且希望损害不会阻止Mercurial将变更集拉到此之外。

您可以尝试的第三个选项是在您的存储库（hg convert repo repo-copy）上运行Mercurial-Mercurial转换;如果保持变更集ID完好无损，则应逐字转换，尽管它可能会遇到同样的问题。您还可以尝试指定filemap来过滤掉ViewInstanceAdapter文件。

因为损坏的变更集太旧了，并且鉴于Mercurial使用仅附加写入方法，导致此问题的可能原因是硬件故障或某种随机磁盘损坏。

请注意，Mercurial不是备份系统，也不提供冗余。经常备份（在Mercurial的案例中就像'hg push'一样简单）是确保您不会丢失宝贵代码的唯一方法。

我觉得应该警告你的另一个原因是病毒扫描程序或Windows索引服务。这些锁定文件以某种方式阻止它们在短时间窗口中被删除。虽然Mercurial尽力保持稳健，但很难防范所有情况。建议将您的存储库列入白名单，请参阅this note。

Answer 2

我找到了一个解决方案（感谢Laurens Holst），只要你有一个干净的bakcup（没有错误），包括问题修订。

在我的问题中，rev问题是7，我有一个备份，直到第18版。

步骤：

在最后一次公共转速（此处为18）克隆备份存储库
将已损坏的存储库转换拉入克隆版本（当然您现在有两个头但工作目录没有修改）
将克隆的存储库更新到最新版本（小费）

你现在有一个工作的.hg目录：）

在Mercurial中破坏了revlog和orphan revlog - 如何修复？

2 个答案: