軟件測試之Subversion與CVS的對比

　　Subversion 作為CVS 的重寫版和改進版，其目標就是作為一個更好的版本控制軟件，取代目前流行的CVS。Subversion 的主要開發人員都是業界知名的CVS 專家。Subversion支持絕大部分的CVS 功能/命令；Subversion 的命令風格和界面也與CVS 非常接近。當然，不同的地方正是對CVS 的改進。

　　二、全局性的版本編號

　　一個新的版本，并得到一個自增量的版本號N+1，該版本號并不針對某個特定的文件，而是全局性的、針對整個版本庫的。因此，我們可以將Subversion 的版本庫看作是一個文件系統或文件目錄樹的數組。

　　從技術的角度來說，在Subversion 中，“文件foo.c 的第5 版本”這個說法是錯誤的；正確的說法應該是：”文件foo.c 在版本庫被修改了5 次，即執行5 次commit 后是什么樣子？”。顯然，在Subversion 中，版本庫被修改5 次后foo.c 的內容，和被修改了6 次后foo.c 的內容很可能完全一樣，因為版本庫的第6 次修改很可能只修改了版本庫的其他部分，而并沒有對foo.c 的進行修改。相反，在CVS 中，文件foo.c 的第1.1 版本和第1.2 版本總是不同的。

　　Subversion 的全局性版本編號為Subversion 帶來了諸多的優勢：如對目錄或文件執行拷貝，無論涉及多少文件，Subversion 不需要對單個文件依次執行拷貝命令，僅僅需要建立一個指向相應的全局版本號的一個指針即可。

　　三、目錄的版本控制

　　CVS 只能對文件進行版本控制，不能對目錄進行版本控制，因此CVS 沒有任何關于文件“移動”（move） 操作的概念。當人為進行文件移動操作時，CVS 只能注意到，一個文件在一個位置被刪除了，而在一個新位置創建了另外一個文件。由于它不會連接兩個操作，因此也很容易使文件歷史軌跡丟失。設置 CVS 存儲庫時，必須非常謹慎地為每個文件選擇準確的位置，因為在設置之后，幾乎就要一直使用這個位置了。

　　同樣由于CVS 不記錄目錄的版本歷史，CVS 不支持對文件的“重命名”（rename），人為的對文件進行重命名會使得命名前后的文件失去歷史聯系，而記錄歷史本來是版本管理的主要目的。

　　還有，CVS 不支持對文件的“拷貝”（copy），人為的拷貝對CVS 而言，只能看到新的文件的增加，而不能記錄拷貝源文件和目標文件之間的聯系。

　　綜上所述，缺乏對文件“移動”、“重命名”、“拷貝”的支持的根源在于CVS 不能記錄目錄的版本歷史，而這些操作在當前的軟件開發過程中經常發生，這正是Subversion被開發并取代CVS 的主要原因之一。

　　Subversion 將目錄作為一類特殊的文件來處理（事實上，從文件系統的角度來看，目錄確實是一類特殊的文件，當目錄中的子目錄/文件被刪除、重命名、或新的子目錄/文件被創建時，目錄的內容將發生改變）。因此，Subversion 象記錄普通文件的修改歷史一樣記錄對目錄的修改歷史，當發生文件/目錄的移動、重命名或拷貝操作時，Subversion 能夠準確記錄操作前后的歷史聯系。同樣，象對文件的不同歷史版本進行比較一樣，Subversion支持對目錄的不同歷史版本的比較，清晰展現目錄的變化歷史。

　　四、原子性提交

　　從使用者的角度來看，CVS 和Subversion 都支持對多個文件修改的批量提交，但二者在實現方式上存在本質的區別。

原文轉自：http://www.anti-gravitydesign.com