尝试运行 svnadmin verify 导致校验和不匹配 [英] Trying to run svnadmin verify results in checksum mismatch

问题描述

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

I have a 7-year-old repository. In order to do some maintenance I ran svnadmin verify on the repository. I got a checksum mismatch error on several revisions.

我尝试创建一个没有错误修订的转储并重新创建存储库，但是有很多新的修订依赖于错误的修订.处于此状态时，我无法使用 svnadmin dump 备份我的存储库.

I tried to create a dump without the bad revisions and recreate the repository, but there were lots of young revisions which depend on the bad revisions. I cannot backup my repository using svnadmin dump when it is in this state.

是否有针对这些错误的解决方法以创建存储库转储文件?

Is there a workaround for these errors in order to create a repository dump file?

推荐答案

[我知道它在这个问题的另一个答案中有链接，但 SO 答案不应该真正链接到场外资源，我想认为这个答案应该比我自己的个人博客网站寿命更长，所以将其发布在这里以供后代使用.]

[I know it's linked in the other answer to this question, but SO answers shouldn't really link to off-site resources, and I'd like to think this answer should outlive my own personal blog site, so posting it here for posterity.]

由于逐个修订版重建存储库总是一个巨大的痛苦，因此我在存储库的内部进行了一些处理以解决问题.

Since rebuilding the repository revision by revision is always a massive pain, I’ve done some mucking around in the guts of the repository to get around the problem.

症状:

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

Running svnadmin verify on the repository results in a "Checksum mismatch while reading representation". The output here is misleading, because it will say something like "* Verified revision 23″ on the line before the error message. This means that it is in fact revision 24 which is bad. You will also find that if you try to dump the repository, it will successfully dump revisions 0 through 23, but then fail on 24. If you try to dump revisions 0:23 and then 25:HEAD like I did, you’ll probably find that the 25:HEAD revision doesn’t work.

诊断:

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

One (or more) of the changes to files in the revision that is causing problems has a different checksum than the one that the revision file recorded at the time. So when svnadmin verify looks over the contents of the revision and recalculates the checksum it finds that they don’t match and tells you. This means one of two things: 1) the checksum recorded at the time was wrong, and the data in the revision/file is valid, or 2) the data in the revision/file is corrupt, and the checksum at the time was correct.

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

If the file generating the bad checksum is a text file, you might be able to look at the contents of the revision file and check if it’s noticeably corrupt. If the file is binary as mine was, that’s probably not an option. Even more so if the file is large (mine was several hundred MB).

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

2) seems to me more likely, so chances are the file in question is corrupt and you need to fix the data. But if 1) is the case, then all you need to do is fix the checksum. Either way you probably can’t tell at this point – so best to assume it’s gone and work from there, or at least treat it as suspicious and verify it against other sources for the data if possible.

可能的解决方案:

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

If you’re happy to assume that file is corrupt, then you can get your repo back to a verifiable step by changing the checksum saved in the revision file to match the checksum which will be generated from the data as it is now. The data won’t change so you’ll still have to verify it manually or delete it later, but at least you can persuade the repository that you don’t care.

过程:

我在这里假设您直接使用 Linux 上的服务器.我使用 Debian，因此通常可以使用 grep 和 hexedit 等工具(尽管我必须安装 hexedit).同样的原则也适用于 Windows，但工具必须改变.

I’m assuming here you’re working directly with the server on Linux. I use Debian, so tools like grep and hexedit are usually available (although I had to install hexedit). The same principles would apply on Windows, but the tools would have to change.

1) 确定损坏的修订版.这很简单——它是上次成功验证修订版之后的修订版

1) Identify the revision which is corrupt. This is straightforward – it’s the revision after the last successfully verified revision

2) 找出修订版中校验和错误的文件，并在修订版中找到错误的校验和.这更难——修订文件(存储在/repository/db/revs 中)是二进制的，在我的情况下，很大.但是 grep 是你的朋友.svnadmin verify 为您提供当前记录的校验和——它存储在修订文件中，就在文件描述的旁边.这是一个 grep 命令，它在特定的修订文件中搜索我们得到的校验和:

2) Identify the file in the revision which has the bad checksum, and find the bad checksum in the revision. This is harder – the revision files (stored in /repository/db/revs) are binary, and in my case, huge. But grep is your friend here. svnadmin verify gives you the checksum that is currently recorded – this is stored in the revision file, right next to a description of the file. Here’s a grep command that searches the particular revision file for the checksum we’ve been given:

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

这里引号中的长字符串是 svnadmin verify 给我的预期"校验和，以下选项表示假设文件是​​二进制 (-a)，并打印 3 行(-B 3) 之前和 (-A 3) 之后的上下文，每个匹配项，关键是每一行从文件开头的偏移量 (-b).这应该输出文件的 7 行(幸好描述文件及其属性的部分主要是文本)

Here the long string in quotes is the "expected" checksum that svnadmin verify gave me, the following options say to assume that the file is binary (-a), and to print 3 lines of context before (-B 3) and after (-A 3) each match, and crucially the offset of each line from the start of the file (-b). This should output 7 lines of the file (thankfully the section describing the files and their properties is mostly textual)

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 个参数是错误的校验和，我们将在下一步中用到它.

The number at the start of each line is the offset, we’ll use that soon. The cpath line is most interesting – this is the file you can expect to be corrupt. But it’s the :text: line that we need to change to get things working. As described here, (look for the section on the revision file format) this line is of the form " ". We don’t want to change the first 4 parameters – they’re most likely just fine. But the 5th parameter is the bad checksum, and we’ll need that in the next step.

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

3) Change the bad checksum to match the "actual" checksum which the svnadmin verify process is coming up with. Again, this is printed out when you run the verify. To make the change, I used hexedit, which thankfully doesn’t try to load the entire (huge) revision file into memory. You just fire it up, and press Return to enter the offset within the file to jump to. It wants it in hex, so a quick conversion turns 384989653 into 16F279D5. From there you can press Tab to switch to ASCII editing, quickly find the offending checksum and overwrite it with the new, valid checksum; then press Ctrl-X to save out the file and exit.

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

4) Re-run svnadmin verify. It should now successfully verify the broken revision and move on. If it doesn’t, check to see if the revision and checksum it’s failing on are the same – if they’re not then you have more broken files/revisions, and you should repeat steps 1 to 3 until they’re all gone. Hopefully there won’t be too many of them. And remember – just because your repository is now verifiable, doesn’t mean that your data is valid. All you’ve done is told the svnadmin tool that the checksum for the data you have is the same as the checksum it expects.

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

Hopefully this will be helpful to other SVN administrators out there.

这篇关于尝试运行 svnadmin verify 导致校验和不匹配的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！