SVN 兩種存儲格式（BDB和FSFS）

Berkeley DB

在Subversion的初始設計階段，開發者因爲多種原因而決定採用Berkeley DB，比如它的開源協議、事務支持、可靠性、性能、簡單的API、線程安全、支持遊標等。
Berkeley DB提供了真正的事務支持－這或許是它最強大的特性，訪問你的Subversion版本庫的多個進程不必擔心偶爾會破壞其他進程的數據。事務系統提供的隔離對於任何給定的操作，Subversion版本庫代碼看到的只是數據庫的靜態視圖－而不是一個在其他進程影響不斷變化的數據庫－並能夠根據該視圖作出決定。如果該決定正好同其他進程所做操作衝突，整個操作會回滾，就像什麼都沒有發生一樣，並且Subversion會優雅的再次對更新的靜態視圖進行操作。
Berkeley DB另一個強大的特性是熱備份－不必“脫機”就可以備份數據庫環境的能力。（備份問題在本文暫不討論）
Berkeley DB同時是一個可信賴的數據庫系統。Subversion利用了Berkeley DB可以記日誌的便利，這意味着數據庫先在磁盤上寫一個日誌文件，描述它將要做的修改，然後再做這些修改。這是爲了確保如果如果任何地方出了差錯，數據庫系統能恢復到先前的檢查點—一個日誌文件認爲沒有錯誤的位置，重新開始事務直到數據恢復爲一個可用的狀態。關於Berkeley DB日誌文件的更多信息可以參考svn中文使用說明中的“管理磁盤空間”一節。
但是每朵玫瑰都有刺，我們也必須記錄一些Berkeley DB已知的缺陷。首先，Berkeley DB環境不是跨平臺的。你不能簡單的拷貝一個在Unix上創建的Subversion版本庫到一個Windows系統並期望它能夠正常工作。儘管Berkeley DB數據庫的大部分格式是不受架構約束的，但環境還是有一些方面沒有獨立出來。其次，使用Berkeley DB的Subversion不能在95/98系統上運行—如果你需要將版本庫建在一個Windows機器上，請裝到Windows2000或WindowsXP上。另外，Berkeley DB版本庫不能放在網絡共享文件夾中，儘管Berkeley DB承諾如果按照一套特定規範的話，可以在網絡共享上正常運行，但實際上已知的共享類型幾乎都不滿足這套規範。
最後，因爲Berkeley DB的庫直接鏈接到了Subversion中，它對於中斷比典型的關係型數據庫系統更爲敏感。大多數SQL系統，舉例來說，有一個主服務進程來協調對數據庫表的訪問。如果一個訪問數據庫的程序因爲某種原因出現問題，數據庫守護進程察覺到連接中斷會做一些清理。因爲數據庫守護進程是唯一訪問數據庫表的進程，應用程序不需要擔心訪問許可的衝突。但是，這些情況與Berkeley DB不同。Subversion（和使用Subversion庫的程序）直接訪問數據庫的表，這意味着如果有一個程序崩潰，就會使數據庫處於一個暫時的不一致、不可訪問的狀態。當這種情況發生時，管理員需要讓Berkeley DB恢復到一個檢查點，這的確有點討厭。除了崩潰的進程，還有一些情況能讓版本庫出現異常，比如程序在數據庫文件的所有權或訪問權限上發生衝突。因爲Berkeley DB版本庫非常快，並且可以擴展，非常適合使用一個單獨的服務進程，通過一個用戶來訪問—比如Apache的httpd或svnserve（可以參考svn中文使用說明中的 配置服務器）—而不是多用戶通過file:///或svn+ssh://URL的方式多用戶訪問。如果將Berkeley DB版本庫直接用作多用戶訪問，可以參考svn中文使用說明中的“支持多種版本庫訪問方法”一節。

FSFS
在2004年中期，另一種版本庫存儲系統慢慢形成了：一種不需要數據庫的存儲系統。FSFS版本庫在單一文件中存儲修訂版本樹，所以版本庫中所有的修訂版本都在一個子文件夾中有限的幾個文件裏。事務在單獨的子目錄中被創建，創建完成後，一個單獨的事務文件被創建並移動到修訂版本目錄，這保證提交是原子性的。因爲一個修訂版本文件是持久不可改變的，版本庫也可以做到熱備份，就象Berkeley DB版本庫一樣。
修訂版本文件格式代表了一個修訂版本的目錄結構，文件內容，和其它修訂版本樹中相關信息。不像Berkeley DB數據庫，這種存儲格式可跨平臺並且與CPU架構無關。因爲沒有日誌或用到共享內存的文件，數據庫能被網絡文件系統安全的訪問和在只讀環境下檢查。缺少數據庫花消同時也意味着版本庫的總體體積可以稍小一點。
FSFS也有一種不同的性能特性。當提交大量文件時，FSFS使用O(N)算法來追加條目，而Berkeley DB則用(N^2)算法來重寫整個目錄。另一方面，FSFS通過寫入與上一個版本比較的變化來記錄新版本，這也意味着獲取最新修訂版本時會比Berkeley DB慢一點，提交時FSFS也會有一個更長的延遲，在某些極端情況下會導致客護端在等待迴應時超時。
最重要的區別是當出現錯誤時FSFS不會楔住的能力。如果使用Berkeley DB的進程發生許可錯誤或突然崩潰，數據庫會一直無法使用，直到管理員恢復。假如在應用FSFS版本庫時發生同樣的情況，版本庫不會受到任何干擾，最壞情況下也就是會留下一些事務數據。
唯一真正對FSFS不利的是相對於Berkeley DB的不成熟，缺乏足夠的使用和壓力測試，許多關於速度和可擴展性的判斷都是建立在良好的猜測之上。在理論上，它承諾會降低管理員新手的門檻並且更加不容易發生問題。在實踐中，只有時間可以證明。
總之，這兩個中並沒有一個是更正式的，訪問版本庫的程序與採用哪一種實現方式無關。通過上文和下表（從總體上比較了Berkeley DB和FSFS版本庫），讀者可以自行選擇自己需要的存儲方式