Subversion存储库错误

在重命名文件和目录后,我在一段时间内对svnadmin 1.5犯了同样的错误。具体地说,我将一些文件从“文件名”重命名为“文件名”,SVN假装这是可以的…后来我试着重新结账的时候,我才发疯。当我尝试一个新的结帐时,我收到一个奇怪的关于文件不存在的中止消息。

因此,这自然会导致我执行svnadmin转储,然后执行svnadmin验证,只获取您指定的相同消息。

我不知道怎么解决。我是这样解决这个问题的:

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

确保转储文件中包含所有的delta,这样就可以将更改历史记录保存到最后一点。

我丢失了一些代码,但不至于太痛苦。

您应该确保使用的是正确版本的 svnadmin 用于存储库版本。使用错误的版本可能会导致这样的错误。

尽管如此,1.3.x版本现在已经很旧了,您应该考虑升级到最新的1.5.x版本。

我还通过谷歌发现 some versions of SVNKit 可能导致此问题。

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

关于未来的预防措施: 我同意Greg Hewgill的观点:在Subversion 1.3.1中有几个已知的数据存储库损坏错误。最后一个已知的补丁是在1.4.6版本中(当然也包括所有1.5.x和所有未来版本中)。因此,如果可能,您可以升级到Ubuntu8.04(dapper-drake),它附带了Subversion1.4.6(以及一些ext3文件系统补丁)。如果升级到dapper-drake,请确保使用e2fslibs的dapper-drake版本重新格式化ext3分区,并对此执行错误的块检查(在大分区上这可能需要几个小时): E2FSCK-C-C-J/DEV公司/

而且,在许多情况下,它不是颠覆性的,而是底层平台(即大多数情况下的硬件)。Subversion信任基础平台,不单独进行校验和检查。这意味着,如果您确实有一个有价值的源代码存储库,并且不想不时地回放未损坏存储库备份版本的备份,那么您应该投资一些钱,将存储库放在一个专用的盒子上,该盒子具有ECC内存、Solaris操作系统和ZFS文件系统,该盒子位于3路RAID-1 ZFS镜像(Redund三个驱动器上的Ant ZFS Softare RAID镜像)。ZFS在进入存储控制器之前对每一位进行校验和,而ext3则没有。

确实发生硬件位错误 在现实生活中一次又一次。颠覆并没有发现那些。因此,您必须将操作系统与执行校验和检查以及ECC内存的文件系统一起使用。