Subversion仓库错误

Question

这个问题让我很困惑。

我在Ubuntu上运行Subversion 1.3.1 (r19032)。最近在尝试运行svnadmin verify之前，一切都很好。但出现了以下错误信息：

svnadmin: Invalid diff stream: insn 0 cannot be decoded

我已经寻找解释和解决方法，但似乎找不到。需要Subversion专家的帮助。

- Neil Albrock

Answer 1

请确保您使用的是与存储库版本相对应的正确版本的svnadmin。如果使用错误的版本，可能会出现此类错误。

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

我还通过谷歌发现一些SVNKit版本可能会导致此问题。

- Greg Hewgill

Answer 2

很遗憾，我不知道如何解决您的实际问题。

关于未来的预防措施：

我同意Greg Hewgill的看法：在subversion 1.3.1中存在几个已知的数据存储库损坏错误。最后一个已知错误在1.4.6中得到修复（当然也在所有1.5.x和所有未来版本中得到修复）。因此，如果可能的话，您可以升级到Ubuntu 8.04（dapper drake），它带有subversion 1.4.6（以及一些ext3文件系统补丁）。如果您升级到dapper drake，请确保使用dapper drake版本的e2fslibs重新格式化您的ext3分区，并进行故障块检查（这可能需要几个小时才能完成大分区）：

e2fsck -c -c -j /dev/

此外，在许多情况下，造成存储库损坏的并不是subversion，而是底层平台（即在大多数情况下是硬件）。Subversion信任底层平台，并不自行进行校验和。这意味着，如果您真的拥有有价值的源代码存储库，不想不时地回放未损坏的存储库备份版本的备份，则应投资一些资金，将存储库放在具有ECC内存、Solaris操作系统和ZFS文件系统的专用盒子上，在三路RAID-1 ZFS镜像上进行（冗余的zfs软件raid镜像，使用三个驱动器）。ZFS在将每个位发送到存储控制器之前都会进行校验和，而ext3不会。

硬件位错误确实会在现实生活中不断发生。Subversion无法检测到这些错误。因此，您必须使用具有进行校验和以及ECC内存的文件系统的操作系统。

- SAL9000

Answer 3

我曾经在重命名文件和目录后使用svnadmin 1.5时遇到了同样的错误。具体来说，我将一些文件从“Filename”重命名为“filename”，SVN假装这是可以的...只有当我尝试进行全新的checkout时才会出现问题。当我尝试进行全新的checkout时，我收到了一个关于文件不存在的奇怪中止消息。

因此，我自然而然地进行了svnadmin dump，然后进行了svnadmin verify，结果得到了您指定的相同消息。

我不知道有什么解决方法。我通过以下方式解决了这个问题：

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

确保您的转储文件具有所有增量，以便获得更改历史记录直到最后一个良好点。

我失去了一些代码，但并不痛苦。

- austirg

---

这是SVN开发人员想要听到的内容 - SVN应该是不区分大小写的，这让Windows用户很烦恼 :) - gbjbaanb