SVN與CVS的區別精辟講解大全
本文向大家介紹一下SVN與CVS的區別，大家應該知道SVN與CVS都是版本控制軟件，那么他們之間有什么區別呢？通過本文的學習相信你會找到答案。
全局性的版本編號
通過全局性的版本編號看SVN與CVS的區別：一個新的版本，并得到一個自增量的版本號N+1，該版本號并不針對某個特定的文件，而是全局性的、針對整個版本庫的。因此，我們可以將Subversion的版本庫看作是一個文件系統或文件目錄樹的數組。Subversion的全局性版本編號為Subversion帶來了諸多的優勢：如對目錄或文件執行拷貝，無論涉及多少文件，Subversion不需要對單個文件依次執行拷貝命令，僅僅需要建立一個指向相應的全局版本號的一個指針即可。
目錄的版本控制
通過目錄的版本控制看SVN與CVS的區別：CVS只能對文件進行版本控制，不能對目錄進行版本控制，因此CVS沒有任何關于文件“移動”（move）操作的概念。當人為進行文件移動操作時，CVS只能注意到，一個文件在一個位置被刪除了，而在一個新位置創建了另外一個文件。由于它不會連接兩個操作，因此也很容易使文件歷史軌跡丟失。設置CVS存儲庫時，必須非常謹慎地為每個文件選擇準確的位置，因為在設置之后，幾乎就要一直使用這個位置了。
Subversion將目錄作為一類特殊的文件來處理（事實上，從文件系統的角度來看，目錄確實是一類特殊的文件，當目錄中的子目錄/文件被刪除、重命名、或新的子目錄/文件被創建時，目錄的內容將發生改變）。因此，Subversion象記錄普通文件的修改歷史一樣記錄對目錄的修改歷史，當發生文件/目錄的移動、重命名或拷貝操作時，Subversion能夠準確記錄操作前后的歷史聯系。同樣，象對文件的不同歷史版本進行比較一樣，Subversion支持對目錄的不同歷史版本的比較，清晰展現目錄的變化歷史。
原子性提交
通過原子性提交看SVN與CVS的區別：從使用者的角度來看，CVS和Subversion都支持對多個文件修改的批量提交，但二者在實現方式上存在本質的區別。
CVS采用線性、串行的批量提交，即依次地，一個接一個地執行提交，每成功提交一個文件，該文件的一個新的版本即被記錄到版本庫中，提交時用戶提供的日志信息被重復地存儲到每一個被修改的文件的版本歷史中。
CVS串行批量提交模式的弊端在于－當任何原因造成批量操作的中斷時（典型原因包括：網絡中斷、客戶端死機等），版本庫往往處于一個不一致的狀態：原本應該全部入庫的文件只有一部分入庫，很有可能版本庫中的最新版本不能順利編譯，更為嚴重的是，隨著其他的用戶執行cvsupdate操作，該不一致性將迅速在開發團隊中擴散，從而嚴重影響團隊的開發效率，并存在質量隱患。另外，假如該批量提交的中斷沒有被及時發現，開發團隊往往要花更多的時間進行軟件調試和排錯。
差異化的二進制文件處理
通過差異化的二進制文件處理看SVN與CVS的區別：由于歷史原因，CVS主要是為早期的程序員設計的，CVS能夠有效處理文本文件（或ASCII文件，源代碼文件），可以對文本文件進行差異化的存儲、新舊版本的比較，文件合并等；但對于二進制文件，CVS則明顯力不從心。
與CVS不同，Subversion采用統一的二進制差異算法（binarydifferencingalgorithm），即對文本文件和二進制文件采用相同的差異比較算法，并以相同的方式在版本庫中進行存儲：每次提交后版本庫中只存儲相對于先前版本的差異，從而可以節省大量的存儲空間。該二進制差異算法不僅應用在版本的存儲上，更為重要的是，Subversion對二進制文件與文本文件一視同仁，當客戶端需要獲取新的版本時（如執行svnupdate），在網絡上只有版本的差異被傳輸，從而大大減少對網絡帶寬的消耗。更多細節參見“七、雙向的差異化－壓縮網絡傳輸”。
【編輯推薦】
- MyEclipse6.0集成SVN及配置詳解
- CentOS系統中安裝subversion并使用svn+ssh訪問
- 基于Java的svn客戶端工具JavaSVN 1.1.0.beta發布
- 如何結合使用Subversion和Eclipse
- Subversion日期解析函數緩沖區溢出漏洞
