mercurial - 当 hg 恢复中止时如何恢复存储库？

Question

由于未知原因，HG 命令失败并显示以下消息:

abort: abandoned transaction found - run hg recover!

但是当我尝试使用recover来摆脱废弃的交易时，我得到了一个不同的错误:

$ hg recover
rolling back interrupted transaction
attempted to truncate path/to/file to 12345 bytes, but it was already 456 bytes

然后就中止了。实际文件的命名如下:

_some_filename.cs.i

这是一个内部 HG 数据文件。因此，some_filename.cs 的 HG 数据记录似乎已严重损坏。事实上，运行 hg verify 会显示如下错误:

# hg verify
checking changesets
checking manifests
crosschecking files in changesets and manifests
checking files
 warning: revlog 'data/project/folder/some_filename.cs.i' not in fncache!
 13691: empty or missing project/folder/some_filename.cs
 project/folder/some_filename.cs@13691: manifest refers to unknown revision b269f6036278
 project/folder/some_filename.cs@13741: manifest refers to unknown revision 651b96abf6da
 ...

(持续很长时间)

这证实了文件已损坏，但没有做任何有用的事情来修复它。

hg recovery --help 没有显示我可以做的任何其他事情...

除了这个文件明显损坏之外，此时普通的 HG 命令不起作用。他们都报告存储库已损坏。我该如何恢复？

Answer 1

我的结论是，这只是 HG 无法处理的情况。无论出于何种原因，HG 的内部数据文件(.i 文件)被破坏。

查看产生关键错误的 HG 源代码很有帮助:

if fp.tell() < o:
    raise error.Abort(
        _(
            b"attempted to truncate %s to %d bytes, but it was "
            b"already %d bytes\n"
        )
        % (f, o, fp.tell())
    )

( https://fossies.org/linux/mercurial/mercurial/transaction.py )

我对 HG 的内部结构不是特别熟悉，但这似乎足够清楚地表明 HG 无法处理这种情况(可以理解 - 任意破坏其数据文件之一几乎没有选择!)。

我能想到的最佳解决方法是从存储库的另一个副本(在另一台 PC 上)手动复制损坏的 .i 文件。我实际上没有对该源文件进行本地更改，因此这似乎是合理的。

我复制了该文件(先备份并替换损坏的原始文件)。

然后运行hg recovery。 现在能够解决原来的“放弃交易”问题。其他 HG 命令也可以工作。

值得注意的是，运行 hg verify 仍然会报告一些错误(尽管少得多)。也许这个单一文件的历史仍然不正确；最终我认为我需要重新克隆这个存储库，但至少我可以完成我的即时任务而不会丢失任何工作。