Subversion版本库错误

Question

这一个让我挠了挠头。

我在Ubuntu上运行Subversion 1.3.1（r19032）。一直很好，直到最近我试图在转储之前运行svnadmin验证。这是错误消息：

svnadmin的：无效的差异流：insn的0 不能被解码

我已经看了看周围的解释和解决，但似乎无法找到一个。颠覆专家，我需要你的帮助。

Answer 1

在重命名文件和目录后，我在svnadmin 1.5中出现了同样的错误。具体来说，我将一些文件从“文件名”重新命名为“文件名”，SVN假装这样做是可以的......只有在我尝试重新结帐时才会吓退。当我尝试了一个新的结帐时，我得到了一个关于这些文件不存在的奇怪的中止消息。

所以这自然导致我做一个svnadmin转储，其次是svnadmin验证只是为了得到您指定的相同的消息。

我不知道修复。我解决了这个问题，如下所示：

1. 转储下一个版本的存储库，并在转储中运行svnadmin验证。
2. 如果仍然出现错误，请转到步骤1.
3. 验证好转储后，我删除了整个SVN存储库，重新创建它，并从良好的转储文件中导入。

确保您的转储文件具有所有增量变化，因此您可以获得最后一个优点的变更历史记录。

我失去了一点代码，但不是太多，真的很痛苦。

Answer 2

您应确保您的存储库版本使用的是svnadmin的正确版本。通过使用错误的版本可能会出现这样的错误。

话虽如此，版本1.3.x现在已经很老了，你应该考虑升级到最新的1.5.x.

我也发现通过谷歌some versions of SVNKit可以导致这个问题。

Answer 3

不幸的是，我不知道如何解决你的实际问题。

关于未来的预防措施： 我同意Greg Hewgill：在Subversion 1.3.1中有几个已知的数据存储库损坏错误。最后一个已知的修补程序在1.4.6中进行了修补（并且修补了所有1.5.x以及所有将来的版本）。所以你可以升级到Ubuntu 8.04（dapper drake），如果可能的话，它附带了subversion 1.4.6（以及一些ext3文件系统补丁）。如果你升级到精简版的德雷克，请确保使用e2fslibs的精简版德雷克版本重新格式化ext3分区，并对此做一个坏块检查（这可能需要几个小时才能在大分区上）： e2fsck -c -c -j/dev/

此外，在很多情况下，它不是颠覆造成存储库损坏，而是底层平台（即大多数情况下的硬件）。 Subversion相信底层平台，不会自行进行校验和。这意味着，如果您真的拥有一个有价值的源代码存储库，并且不希望必须时常回放未损坏的存储库备份版本的备份，则应比投入一些资金并将存储库放在具有ECC内存的专用盒上， Solaris操作系统和ZFS文件系统位于3路RAID-1 ZFS镜像（三个驱动器上的冗余zfs softare RAID镜像）。在进入存储控制器之前，ZFS会对每一位进行校验，而ext3则不会。

硬件位错误确实发生在现实生活中一次又一次。 Subversion没有检测到这些。所以你必须使用一个带有校验和以及ECC内存的文件系统的操作系统。