试图运行svnadmin验证结果校验和不匹配

Question

我有一个7岁的存储库。为了做一些维护，我在版本库上运行了svnadmin verify。我得到了一个校验和不匹配错误的几个修订。

我试着不坏修订创建转储和创建资源库，但也有很多这取决于坏修订年轻的修订。处于此状态时，我无法使用svnadmin dump备份我的存储库。

是否有这些错误的解决方法来创建存储库转储文件？

Answer 1

一些谷歌搜索后，我发现了以下post。
按照这些指导原则，我能够'修复'错误的版本并完成一个完整的svnadmin验证命令。另外，它允许我创建存储库的完整转储。

这种解决方案的缺点是，它实际上并没有修不好的修订。它只是让他们干净，以便SVN正确处理它们。我假设如果我尝试在这些修订版本中签出文件，我可能会收到错误。

希望能帮助任何人。

Answer 2

[我知道它与这个问题的其他答案有联系，但SO答案不应该真正链接到非现场资源，我想这个答案应该超过我自己的个人博客网站，所以发布在这里为后人。]

由于通过修正重建库修订始终是一个巨大的痛苦，我已经做了在库的胆量一些碴各地去解决问题。

症状：

运行的svnadmin在库结果验证了一个“校验和不匹配，而读的表示”。这里的输出具有误导性，因为它会在错误消息之前的行中显示“* Verified revision 23”之类的内容。这意味着它实际上是第24版，这是不好的。你也会发现，如果你试图转储版本库，它将成功地转储修订版0到23，但是随后在24上失败。如果你尝试转储修订版0:23然后是25：HEAD，像我一样，你可能会发现25：HEAD修订版不起作用。

诊断：

在这导致的问题有不同的校验比修正文件记录当时的一个修改的文件更改一个（或多个）。因此，当svnadmin verify查看修订内容并重新计算校验和时，它发现它们不匹配并告诉您。这意味着两件事之一：1）当时记录的校验和错误，并且修订版/文件中的数据有效，或者2）修订版/文件中的数据损坏，并且当时的校验和正确。

如果文件生成的校验和错误是一个文本文件，你也许可以看看修订文件的内容，并检查它是否是明显损坏。如果这个文件是我的二进制文件，那可能不是一个选项。如果文件很大（我的是几百MB）更是如此。

2）在我看来，更可能，因此机会是有问题的文件已损坏，需要修复的数据。但是如果1）是这种情况，那么你所要做的就是修复校验和。无论哪种方式，您现在可能无法说出 - 最好假设它已经消失并且从那里开始工作，或者至少将其视为可疑，并在可能的情况下将其与其他数据源进行验证。

可能的解决方案：

如果你感到快乐假设文件已损坏，则可以通过更改保存在修改文件的校验，以匹配校验让你的回购回核实的步骤，将会像现在一样从数据中生成。数据不会改变，因此您仍然需要手动验证或稍后删除，但至少可以说服您不关心的存储库。

过程：

我假设在这里你直接在Linux服务器工作。我使用Debian，因此通常可以使用像grep和hexedit这样的工具（尽管我必须安装hexedit）。 Windows也适用同样的原则，但这些工具必须改变。

1）确定损坏的版本。这很简单 - 它是最后一次成功验证修订版本后的修订

2）识别修订版本中具有错误校验和的文件，并在修订中找到错误的校验和。这很难 - 修订文件（存储在/ repository/db/revs）是二进制文件，在我的情况下是巨大的。但grep是你的朋友。 svnadmin verify为您提供当前记录的校验和 - 它存储在修订文件中，紧挨着文件的描述。下面是搜索校验的特定版本文件grep命令我们已经给出：

grep -e "79a1686d0dfb8618b8ccfc9eb7d74759" -A 3 -B 3 -b -a main/db/revs/24

在这里，在引号中的长字符串是“预期”校验和svnadmin的校验给我，以下选项说假设该文件是二进制(-a)，并且打印3行上下文前(-B 3)和(-A 3)每个匹配，并且关键是从文件(-b)开始的每行的偏移量。这应该输出7行的文件（谢天谢地描述文件及其属性的部分主要是文本）

384989609-id: 5cu.0.r24/384989609 
384989633-type: file 
384989644-count: 0 
384989653:text: 24 75689685 293851064 294285337 79a1686d0dfb8618b8ccfc9eb7d74759 
384989724-props: 24 384989543 53 0 113136892f2137aa0116093a524ade0b 
384989782-cpath: /path/to/the/bad/file.exe 
384989842-copyroot: 0/

的数量在每行的开始偏移，我们会尽快使用。 cpath线是最有趣的 - 这是你可以期望损坏的文件。但它是：text：line，我们需要改变才能使事情顺利进行。如此处所述（查找修订文件格式的部分），此行的格式为“”。我们不想改变前4个参数 - 它们很可能没问题。但是第五个参数是错误的校验和，我们将在下一步中使用它。

3）更改错误的校验和以匹配svnadmin验证过程所提供的“实际”校验和。再次，当您运行验证时会打印出来。为了进行更改，我使用了hexedit，幸好没有尝试将整个（巨大的）修订版文件加载到内存中。您只需启动它，然后按回车键即可在文件中输入要跳转的偏移量。它希望在十六进制中，所以快速转换将384989653转换为16F279D5。从那里你可以按Tab切换到ASCII编辑，快速找到有问题的校验和并用新的有效校验和覆盖它;然后按Ctrl-X将文件保存并退出。

4）重新运行svnadmin验证。它现在应该能够成功验证破损的修订并继续前进。如果没有，请检查它的修订版本和校验和是否相同 - 如果它们不是，那么你的文件/修订版本会更多，并且应该重复步骤1到3，直到它们全部消失。希望不会有太多。请记住 - 仅仅因为您的存储库现在可以验证，并不意味着您的数据是有效的。你所做的所有事情都被告知svnadmin工具，你所拥有的数据的校验和与它期望的校验和相同。

希望这会对其他SVN管理员有所帮助。