版本控制是管理信息變更的一門藝術。Subversion版本控制工具早已經成為許多程序員的主要工具之一。但是版本控制軟件的用途并不僅限于軟件開發的領域。只要人們使用計算機來管理經常變更的信息，就需要使用版本控制工具。而這正是 Subversion 可以展示自己的地方。

下面我們來看一下版本控制:Subversion與CVS的對比：

一、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帶來了諸多的優勢：如對目錄或文件執行拷貝，無論涉及多少文件，ubversion不需要對單個文件依次執行拷貝命令，僅僅需要建立一個指向相應的全局版本號的一個指針即可。　　

三、目錄的版本控制

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

同樣由于CVS不記錄目錄的版本歷史，CVS不支持對文件的“重命名”(rename)，人為的對文件進行重命名會使得命名前后的文件失去歷史聯系，而記錄歷史本來是版本管理的主要目的。還有，CVS不支持對文件的“拷貝”(copy)，人為的拷貝對CVS而言，只能看到新的文件的增加，而不能記錄拷貝源文件和目標文件之間的聯系。

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

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

四、原子性提交

從使用者的角度來看，CVS和Subversion版本控制都支持對多個文件修改的批量提交，但二者在實現方式上存在本質的區別。CVS采用線性、串行的批量提交，即依次地，一個接一個地執行提交，每成功提交一個文件，該文件的一個新的版本即被記錄到版本庫中，提交時用戶提供的日志信息被重復地存儲到每一個被修改的文件的版本歷史中。

CVS串行批量提交模式的弊端在于-當任何原因造成批量操作的中斷時(典型原因包括：網絡中斷、客戶端死機等)，版本庫往往處于一個不一致的狀態：原本應該全部入庫的文件只有一部分入庫，很有可能版本庫中的最新版本不能順利編譯，更為嚴重的是，隨著其他的用戶執行cvsupdate操作，該不一致性將迅速在開發團隊中擴散，從而嚴重影響團隊的開發效率，并存在質量隱患。另外，假如該批量提交的中斷沒有被及時發現，開發團隊往往要花更多的時間進行軟件調試和排錯。

CVS即使在批量提交不發生中斷時也會造成不一致：假設用戶A啟動一個需要較長時間才能完成的批量提交;與此同時，用戶B執行cvsupdate操作。此時，用戶B很有可能得到一個不一致的更新，即用戶B通過“更新”操作，得到用戶A的部分修改文件。

Subversion徹底消除了CVS的以上弊端。無論批量提交包含多少文件修改，只有當全部文件修改都成功入庫，該提交才變得有效，才對其他用戶可見;否則，無論任何原因造成中斷，Subversion都會自動執行“回滾”(rollback)操作。換一個說法，Subversion保證所有的修改要么全部入庫生效，要么一個也不入庫，即對版本庫不作任何的修改。這就是Subversion的原子性提交(atomiccommit)。

由于Subversion的原子性提交特性和全局版本編號方式，當提交成功完成時，一個唯一的、新的全局版本編號產生，而提交時用戶提供的日志信息與該新的版本編號關聯，只進行一次存儲(區別于CVS的按文件重復存儲)。

【編輯推薦】

1. 三大主流Subversion客戶端初探
2. Windows下Subversion管理配置詳細說明
3. 七步搞定Subversion服務器在Ubuntu下的配置
4. Subversion SVN協議解析遠程整數溢出漏洞
5. CentOS系統中安裝subversion并使用svn+ssh訪問