1

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

我试图创建一个没有错误修订的转储并重新创建存储库，但是有很多年轻的修订依赖于错误的修订。svnadmin dump当它处于这种状态时，我无法使用它来备份我的存储库。

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

4

2 回答 2

3

[我知道它与此问题的其他答案相关联，但 SO 答案不应该真正链接到场外资源，我想这个答案应该比我自己的个人博客网站寿命更长，因此将其发布在这里以供后代使用.]

由于通过修订来重建存储库修订总是一个巨大的痛苦，我在存储库的内部做了一些处理来解决这个问题。

症状：

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

诊断：

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

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

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

可能的解决方案：

如果您乐于假设文件已损坏，那么您可以通过更改保存在修订文件中的校验和以匹配将从数据生成的校验和，从而使您的 repo 回到可验证的步骤。数据不会改变，因此您仍然需要手动验证它或稍后将其删除，但至少您可以说服存储库您不在乎。

过程：

我假设您在这里直接使用 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 verify 给我的“预期”校验和，以下选项说假设文件是​​二进制文件(-a)，并在每次匹配之前(-B 3)和之后打印 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: 行以使事情正常进行。如此处所述，（查找有关修订文件格式的部分）该行的格式为“ ”。我们不想更改前 4 个参数——它们很可能就可以了。但是第 5 个参数是错误的校验和，我们将在下一步中需要它。

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

4) 重新运行 svnadmin 验证。它现在应该成功验证损坏的修订并继续前进。如果不是，请检查它失败的修订和校验和是否相同 - 如果它们不同，那么您有更多损坏的文件/修订，您应该重复步骤 1 到 3，直到它们全部消失。希望他们不会太多。请记住——仅仅因为您的存储库现在是可验证的，并不意味着您的数据是有效的。您所做的只是告诉 svnadmin 工具，您拥有的数据的校验和与其期望的校验和相同。

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

于 2014-04-23T10:39:17.750 回答
1

经过一番谷歌搜索后，我发现了以下帖子。
遵循这些指南，我能够“修复”错误的修订并完成完整的 svnadmin verify 命令。此外，它还允许我创建存储库的完整转储。

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

希望对任何人都有帮助。

于 2013-08-22T13:20:08.233 回答