Subversion 儲存庫損壞
我剛剛遇到一個問題，一個新創建的 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 是此儲存庫上使用的客戶端，我自己的測試是通過命令行版本完成的。
我能夠隔離原因，它似乎來自一個不完整的送出，當送出失敗時以某種方式沒有被拋出。