SVN存储库如何损坏？

我已经有过几次遇到这样的情况，我的一个SVN存储库被破坏了，我们可以在不知道我们做了什么的情况下对项目的某些版本或分支做任何事情。所以我想问的是，什么会导致存储库损坏

---

---

客户端之间的不兼容可能会导致问题，尤其是字符集。

潜在的文件系统损坏或有人在处理内部svn目录？

我已经发生过几次了。SVN似乎不能很好地处理当服务器花费很长时间做某些事情时客户端离开的情况。我不知道确切的细节，但我对我认为是只读的进程做了一些

kill-9

s，最后不得不在服务器再次响应之前运行

svnadmin cleanup

。

这在基于

文件的repo上非常常见，但是，如果只有一个用户/服务访问repo，则不会发生这种情况。
始终存在硬件故障的可能性。像内存中的位错误之类的事情会导致无声的破坏，而不是简单地使计算机崩溃；如果受影响的是svn服务器进程，则存储库可能会损坏。
基本上有三种不同的情况：

硬件故障（内存、fs损坏等）
具有服务器登录访问权限的用户可能会损坏存储库文件
颠覆中的bug
除了最明显的情况外，故障硬件通常是最难发现的。案例2可以通过限制对服务器的登录访问来预防其他一切都是Subversion中的一个bug。（这包括客户端和服务器之间的兼容性问题。）您应该永远不能仅通过使用Subversion客户端来损坏存储库（即使客户端有bug，IMO也不行）。
我有一个repo损坏，我花了一段时间才弄清楚。在服务器上，我意外地将repo中.svn dir的所有者更改为某个不相关的用户。SVN在那之后给了我腐败错误，直到我删除并重新创建了回购协议。即使在我纠正它之后。
如果存储库不在svn服务器本地磁盘上，而是在NFS上，则如果使用berkley db格式，存储库可能会损坏。在svn 1.5中，FSFS成为了新repo的默认设置—在非锁定文件系统（如NFS）上生活非常愉快。
svn中没有只读进程；它总是创建一个事务，即使是为了更新。有关详细信息，请参见。svnadmin没有清理命令。svn cleanup是一个客户端命令。在除file:///存储库访问之外的所有情况下，客户端崩溃/挂起都不会损害服务器或数据。。而file:///通过网络访问肯定不是推荐的做法。@Bert:哎呀，我是说svnadmin recover。你不是在使用file:///通过网络访问，是吗？相当多的人，我们处于一个非常异构的环境中。你能扩展一下吗？我想我知道你的意思。如果使用Windows共享之类的东西，请确保只有一个用户。我会非常惊讶地看到Subversion中出现这样的错误。它的目标是在最终版本中不会因为一个bug而丢失一个数据。如果Subversion中没有这样一个bug，潜伏在某个黑暗的角落，我会非常惊讶。每个软件都有一些潜在的非常严重的bug，问题是在什么情况下它会表现出来。我有一个脚本，在一个大的代码库上每两分钟更新一次svn。这是我们通常更新频率的100-1000倍。它似乎每两周就腐败一次。所以我认为这是SVN中的一个bug。