我有一个7岁的存储库。为了进行一些维护，我在存储库上运行了svnadmin verify。我在几次修订时遇到了校验和不匹配错误。
我尝试在没有错误修订的情况下创建转储并重新创建存储库，但是有许多年轻的修订版依赖于错误的修订版。当它处于此状态时，我无法使用svnadmin dump备份我的存储库。
是否有针对这些错误的解决方法来创建存储库转储文件？
答案 0 :(得分：2)
[我知道它在这个问题的另一个答案中有联系，但是SO答案不应该真正链接到异地资源，我想这个答案应该比我的答案更长久自己的个人博客网站，所以在这里张贴后代。]
由于通过修订重建存储库修订版总是一个巨大的痛苦，我已经在存储库的内容中做了一些工作来解决问题。
<强>症状：
在存储库上运行svnadmin verify会导致“读取表示时校验和不匹配”。这里的输出是误导性的，因为它会在错误消息之前的行上说出类似“* Verified revision 23”的内容。这意味着它实际上是修订版24，这是不好的。您还会发现，如果您尝试转储存储库，它将成功转储修订版0到23，但随后24版失败。如果您尝试转储修订版0:23然后25：HEAD就像我做的那样，你可能会发现25：HEAD修订版不起作用。
<强>诊断：
修订中导致问题的文件中的一个（或多个）更改的校验和与当时记录的修订文件的校验和不同。因此，当svnadmin验证查看修订内容并重新计算校验和时，它会发现它们不匹配并告诉您。这意味着以下两点之一：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)，并在{{1}之前打印3行上下文并且在(-B 3)每次匹配之后，以及从文件(-A 3)开始的每一行的偏移量。这应该输出7行文件（幸好描述文件的部分及其属性主要是文本的）
(-b)每行开头的数字是偏移量，我们很快就会使用它。 cpath行最有趣 - 这是你可能会被破坏的文件。但它是：text：line，我们需要改变以使事情有效。如此处所述，（查找修订文件格式的部分）此行的格式为“”。我们不想改变前4个参数 - 它们很可能就好了。但第五个参数是错误的校验和，我们将在下一步中需要它。
3）更改错误校验和以匹配svnadmin验证过程即将出现的“实际”校验和。同样，运行验证时会打印出来。为了进行更改，我使用了hexedit，幸好不要尝试将整个（巨大的）修订文件加载到内存中。你只需启动它，然后按Return键输入文件中的偏移量即可跳转到。它希望它以十六进制表示，因此快速转换会将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 /
变为384989653。从那里你可以按Tab切换到ASCII编辑，快速找到有问题的校验和并用新的有效校验和覆盖它;然后按Ctrl-X保存文件并退出。
4）重新运行svnadmin验证。它现在应该成功验证损坏的修订版并继续。如果没有，检查它的失败的版本和校验和是否相同 - 如果它们不是那么你有更多损坏的文件/版本，你应该重复步骤1到3，直到它们全部消失。希望它们不会太多。请记住 - 只是因为您的存储库现在可以验证，并不意味着您的数据有效。您所做的就是告诉svnadmin工具，您所拥有的数据的校验和与它所期望的校验和相同。
希望这对其他SVN管理员有所帮助。
答案 1 :(得分：1)
经过一些谷歌搜索后，我发现了以下post
遵循这些指导原则，我能够“修复”错误的修订并完成一个完整的svnadmin verify命令。此外，它允许我创建存储库的完整转储。
这个解决方案的缺点是它实际上并没有修复坏的修改。它只是让它们干净让SVN正确处理它们。我假设如果我尝试在这些修订中签出文件，我可能会收到错误。
希望有助于任何人。