我刚刚遇到一个问题，一个新创建的 Subversion 存储库中大约 80% 的修订版本已损坏（最终无法使用时，用户收到文件系统损坏和校验和不匹配错误）。但是，工程师能够使用存储库，甚至可以从损坏的修订版本之一创建分支并更新这些修订版本，直到上述错误开始发生。由于该项目只有一周的历史，我们最终删除并重新创建了它，但如果这个项目有很多历史，情况可能会更糟。我以前处理过存储库损坏问题，但在诊断存储库时看到的一些行为确实让我感到困惑，我希望对可能发生的情况有所了解。
真正奇怪的是，如果我签出项目的 HEAD 修订版本，我会自己得到校验和不匹配和文件系统损坏错误。但是，如果我签出修订版本 1，然后按顺序更新到每个单独的修订版本（包括已知的损坏修订版本），这些错误从未发生过，就像存储库没有任何问题一样（“svnadmin verify”确认确实存在损坏，并且“svnadmin dump”在每个损坏的修订版本上都失败并出现相同的错误）。通常，损坏的修订版本无法更新，这就是为什么我对这里发生的事情感到非常困惑。
这是我 6 年来见过的最奇怪的存储库问题，我希望有人比我更有知识，可以帮助我深入了解可能出了什么问题。我有存储库的备份，因此我能够提取诊断所需的任何信息。
我们目前使用 SCM Manager 来托管 Subversion 和 Git 项目，但自从我们开始使用 SCM Manager 作为源代码控制平台以来，我们还没有看到过类似的事情发生。我们对 1.7 兼容存储库使用 TortoiseSVN 1.8（svnsync 在 1.8 中存在严重问题，因此我们使用 1.7），但我们中的一些人也使用命令行 svn 工具。在这种情况下，TSVN 是此存储库上使用的客户端，我自己的测试是通过命令行版本进行的。
答案1
我能够找出原因，它似乎是由于不完整的提交造成的，而提交失败时它以某种方式没有被抛出。