SVN vs CVS

pascal4123

版本控制系統(tǒng)里團隊開發(fā)不免要用上CVS SVN ClearCase等工具。至于選擇上，則是根據(jù)開發(fā)團隊搭建的平臺，使用的編程語言相關(guān)聯(lián)。
如下節(jié)選一些網(wǎng)上的對比說明。當(dāng)然，真正要弄懂這些版本控制系統(tǒng)，還是要花費巨大工夫?qū)W習(xí)研究，不可能google幾下就能完成的。
一、Subversion包含絕大部分CVS功能

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

二、全局性的版本編號

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

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

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

三、目錄的版本控制

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

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

還有，CVS 不支持對文件的"拷貝"（copy），人為的拷貝對CVS 而言，只能看到新的文件的增加，而不能記錄拷貝源文件和目標(biāo)文件之間的聯(lián)系。

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

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

四、原子性提交

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

CVS 采用線性、串行的批量提交，即依次地，一個接一個地執(zhí)行提交，每成功提交一個文件，該文件的一個新的版本即被記錄到版本庫中，提交時用戶提供的日志信息被重復(fù)地存儲到每一個被修改的文件的版本歷史中。

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

CVS 即使在批量提交不發(fā)生中斷時也會造成不一致：假設(shè)用戶A 啟動一個需要較長時間才能完成的批量提交；與此同時，用戶B 執(zhí)行cvs update 操作。此時，用戶B 很有可能得到一個不一致的更新，即用戶B 通過"更新"操作，得到用戶A 的部分修改文件。

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

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

五、支持變更集概念

由于Subversion
的所有提交是原子性的，每次成功提交形成的唯一的全局版本號對應(yīng)此次批量提交的所有文件修改，也就是說，一個Subversion
版本號其實對應(yīng)了一個邏輯上的變更集（change set），該變更集可能對應(yīng)于對一個BUG
的修復(fù)，或者對應(yīng)于對一個已有功能的改進，或者對應(yīng)于一個新功能的實現(xiàn)�？梢哉f，變更集是一個軟件開發(fā)活動的邏輯結(jié)果，該變更集可以通過其對應(yīng)的版本號在
軟件開發(fā)的其他過程中（如軟件合并/集成過程，軟件發(fā)布管理，變更管理系統(tǒng)，缺陷追蹤系統(tǒng)）被引用。因此，Subversion
將版本管理從單純的、單個的文件修改的層次通過邏輯上的抽象，上升到更便于理解和交流的開發(fā)活動的層次。

六、差異化的二進制文件處理

由于歷史原因，CVS 主要是為早期的程序員設(shè)計的，CVS
能夠有效處理文本文件（或ASCII文件，源代碼文件），可以對文本文件進行差異化的存儲、新舊版本的比較，文件合并等；但對于二進制文件，CVS則明顯
力不從心。在CVS 的版本庫中，對于二進制文件的歷史版本，CVS
唯一能做的就是對不同的版本進行獨立的、冗余的存儲，哪怕版本之間其實只存在微小的差異。舉例而言，一個10M
的二進制文件（照片、圖形文件、機械設(shè)計文件、電子設(shè)計文件）假如每周修改一次，無論每次修改的大小，一年下來，僅該文件就要消耗500M
以上的存儲空間。而且，客戶端每次獲取該文件的新版本都要消耗10M 的網(wǎng)絡(luò)流量。

對于目前的開發(fā)團隊，無論是軟件開發(fā)，Web 站點的開發(fā)，手機等電子產(chǎn)品的研發(fā)，需要進行版本管理的不僅是源代碼等文本文件，還需要管理需求文檔、設(shè)計文檔、測試文檔、用戶手冊，圖形圖像文件，機械/電子設(shè)計文件等諸多的二進制文件，CVS 顯然不是一個好的選擇。

與CVS 不同，Subversion 采用統(tǒng)一的二進制差異算法（binary differencing
algorithm），即對文本文件和二進制文件采用相同的差異比較算法，并以相同的方式在版本庫中進行存儲：每次提交后版本庫中只存儲相對于先前版本的
差異，從而可以節(jié)省大量的存儲空間。

該二進制差異算法不僅應(yīng)用在版本的存儲上，更為重要的是，Subversion
對二進制文件與文本文件一視同仁，當(dāng)客戶端需要獲取新的版本時（如執(zhí)行svn
update），在網(wǎng)絡(luò)上只有版本的差異被傳輸，從而大大減少對網(wǎng)絡(luò)帶寬的消耗。更多細節(jié)參見"七、雙向的差異化－壓縮網(wǎng)絡(luò)傳輸"。

七、 雙向的差異化－壓縮網(wǎng)絡(luò)傳輸

如上所述，CVS 對二進制文件不能進行有效的差異化處理。對于文本文件，CVS 僅僅支持單向的差異化傳輸：從CVS
到客戶端的傳輸是差異化的，即執(zhí)行cvs update 時，只有差異的部分從服務(wù)器傳輸?shù)娇蛻舳耍欢��?dāng)執(zhí)行cvs commit
時，無論代碼變化多少，CVS 都需要從客戶端向服務(wù)器完整傳輸被修改文件的全部內(nèi)容，不能只傳輸差異。

相反，無論是文本文件還是二進制文件，Subversion
都進行雙向的差異化傳輸，并且差異化內(nèi)容還要進行壓縮/解壓縮的過程：在服務(wù)器端獲取差異顯而易見，與CVS 類似；Subversion
在客戶端獲取差異的秘密在于 — Subversion
在客戶端的工作拷貝中隱含了每個文件的一個"只讀的、干凈的"副本（該副本隱藏在隱含目錄.svn
里，通常不可見，該副本還有更多的妙用，參見"十二、更多的本地/離線操作"），通過比較用戶在客戶端的修改和該隱含的副本，Subversion
獲取需要真正傳送到服務(wù)器的差異，并對差異進行壓縮后才進行網(wǎng)絡(luò)傳輸。

對CVS 而言，操作的成本（網(wǎng)絡(luò)帶寬消耗是最大的操作成本）與被修改的文件的大小成比例，而與修改本身的大小無關(guān)；對Subversion
而言，操作成本只與修改本身的大小成比例，而與被修改的文件的大小無關(guān)。因此，與CVS 相比，Subversion
消耗更少的網(wǎng)絡(luò)帶寬（以客戶端的存儲空間換取更少的帶寬消耗在目前的計算環(huán)境下應(yīng)該是個相當(dāng)不錯的選擇�。�。Subversion
更加適合基于互聯(lián)網(wǎng)（或廣域網(wǎng)）進行協(xié)作開發(fā)的地理上分布的團隊 — 版本服務(wù)器集中、單一；客戶端廣泛分布。

八、高效、快捷創(chuàng)建分支和基線

CVS 和Subversion 都支持分支（branch）和基線（tag），通過分支與合并，可以有效支持大項目的并行開發(fā)模式；通過基線管理，可以準(zhǔn)確標(biāo)識一組文件的版本，有效進行軟件發(fā)布管理和必要時的歷史回溯。

但CVS 和Subversion 在實現(xiàn)分支和基線的方式上存在很大的不同。CVS
在創(chuàng)建分支的時候，需要對所有進行分支的文件進行依次的操作，因此分支的建立成本（主要是建立分支所需的時間，或消耗的計算資源）與參與分支的文件數(shù)量成
比例，項目越大，版本庫越大，文件越多，分支的建立成本越高；基線（tag）的建立與此類似。

Subversion
的分支和基線是通過執(zhí)行"拷貝"來建立的：回想一下在沒有引入版本管理工具的時候我們是如何進行所謂的"分支"和"基線"管理的？答案顯然是"拷貝"
—
我們通過"拷貝"或"備份"來建立基線；同樣，為支持多個開發(fā)人員可以同時進行開發(fā)，我們?yōu)槊總�開發(fā)人員創(chuàng)建一份"拷貝"。由此看
來，Subversion 通過"拷貝"來建立分支和基線顯得非常自然，有點"返樸歸真"的意思。

由于Subversion 的全局版本號特性，Subversion
中分支或基線的創(chuàng)建過程，或Subversion中的"拷貝"過程，真正的操作是在版本庫中創(chuàng)建一個到某一全局版本號的指針（pointer），不再需要
針對眾多的單個文件依次執(zhí)行操作。因此，該操作的成本為一個很小的常數(shù)，與項目大小，版本庫大小，文件數(shù)目的多少無關(guān)；并且，分支或基線的建立不需要進行
版本的冗余存儲，新建立的分支或基線基本不占用版本庫空間，分支的后續(xù)存儲空間的開銷也只與修改的大小有關(guān)。

九、集成Apache Web Server，提供更多的特性

Subversion 通過與Apache Web Server 的集成，可以提供基于http/https
協(xié)議的版本庫訪問機制，從而支持Subversion 跨越防火墻的安全訪問。除此以外，Subversion 還可以利用更多的Apache
特性，包括但不限于：Apache 豐富的用戶認證機制（包括通過LDAP服務(wù)器如Windows Active Directory
服務(wù)器的用戶認證），基于目錄路徑的精細粒度的訪問控制，對傳輸?shù)木W(wǎng)絡(luò)流量進行壓縮/解壓縮，瀏覽版本庫目錄結(jié)構(gòu)等等。

十、支持WebDAV
WebDAV（Web-based Distributed Authoring and Versioning）是一種基于 HTTP 1.1
協(xié)議的通信協(xié)議.它擴展了HTTP 1.1，在GET、POST、HEAD 等幾個HTTP
標(biāo)準(zhǔn)方法以外添加了一些新的方法，使應(yīng)用程序可直接對Web Server
直接讀寫，并支持寫文件鎖定(Locking)及解鎖(Unlock)，還可以支持文件的版本控制。
Microsoft windows2000/XP 及IE, Office 還有Adobe/MicroMedia 的DW
等都支持WebDAV，這又大大增強了Web 應(yīng)用的價值，以及效能。對于需要大量發(fā)布內(nèi)容的用戶而言，應(yīng)用WebDAV 可以降低對CMS
系統(tǒng)的依賴，而且能夠更自由的進行創(chuàng)作。上傳、下載變得輕松自如。
Subversion 通過與Apache Web Server 的集成，支持WebDAV 協(xié)議，使得業(yè)務(wù)用戶（business
users）或非技術(shù)用戶在不安裝任何版本管理客戶端的情況下輕松訪問Subversion
版本庫，不改變業(yè)務(wù)用戶已有使用習(xí)慣，支持分布的業(yè)務(wù)用戶對文檔的評審、修改并實現(xiàn)版本控制，真正將軟件開發(fā)的生命周期從開發(fā)/技術(shù)團隊擴展到項目的全部
干系人（stakeholder），避免通過電子郵件傳遞文檔的混亂與無序、通過Windows
操作系統(tǒng)共享造成的安全漏洞、病毒攻擊、歷史版本被覆蓋或丟失、審計困難等諸多典型問題。

十一、更好的沖突標(biāo)識與處理

CVS 和Subversion
都支持通過分支與合并進行并行開發(fā)，并可以自動檢測到合并時的沖突（conflicts），并在合并結(jié)果中
以>>>>>標(biāo)識合并的沖突部分。
在CVS
中，經(jīng)常會出現(xiàn)由于用戶的疏忽（如，沒有注意到?jīng)_突，或沒有完全處理好沖突）而將仍然帶有>>>>>沖突標(biāo)識符號的文件直接進行提交（commit），從而在版本庫中產(chǎn)生垃圾版本。
Subversion 有效解決了CVS 的以上問題：Subversion 記錄并保持文件的沖突狀態(tài)，只有當(dāng)用戶明確執(zhí)行svn
resolved 命令后，該沖突狀態(tài)標(biāo)識才被復(fù)位，該文件才能被提交，從而大大減少了將仍然帶有>>>>>沖突標(biāo)識符號的文件直接進行提交的可能性。

十二、 更多的本地/離線操作

眾所周知，CVS 客戶端的工作拷貝中包含了一個隱含目錄CVS，該目錄中記錄了客戶端需要的一些管理信息；與此類似，Subversion
的客戶端工作拷貝中也包含了一個隱含目錄.svn，該目錄中同樣記錄了客戶端需要的一些管理信息，如版本庫URL，當(dāng)前訪問版本號等。
與CVS 不同的是，Subversion 的.svn
目錄中還包含了工作拷貝中每一個文件的一個"只讀的、干凈的"副本。正是由于該副本的存在，使得Subversion 與CVS
相比，可以執(zhí)行更多的本地/離線操作，即某些操作不需要訪問版本庫服務(wù)器，因此不需要存在從客戶端到服務(wù)器的網(wǎng)絡(luò)鏈接，當(dāng)然也不消耗任何網(wǎng)絡(luò)帶寬，這進一
步增強了Subversion 對廣域網(wǎng)的友好支持。
Subversion 的以下命令可以進行離線操作：
svn status － 顯示工作拷貝上的本地修改概況；
svn diff －顯示工作拷貝上的本地修改細節(jié)，比較修改前后的內(nèi)容；
svn revert － 撤銷工作拷貝上的本地修改；

十三、 對符號鏈接進行版本管理

在Unix 文件系統(tǒng)中，符號鏈接（symbolic links，包括硬鏈接和軟鏈接）是一種重要的文件系統(tǒng)元素。CVS 不能對符號鏈接進行版本管理；Subversion 則可以對符號鏈接進行版本管理。

十四、 元數(shù)據(jù)管理

與CVS 相比，Subversion
增加了元數(shù)據(jù)（metadata）管理機制。即可以對版本庫中的文件或目錄附加任意的"屬性"（property），并記錄屬性的變化歷史，也就是對元數(shù)
據(jù)進行版本管理。一個Subversion 屬性是一個"屬性名稱/屬性值"的二元組，如"BugNumber=
100"就是一個屬性，可以將該屬性附加到版本N 上，以說明版本N 改正了編號為100的BUG。
Subversion 元數(shù)據(jù)的目的是提供附件的信息以滿足流程或過程自動化的需要，以增強Subversion
的管理能力和自動化程度。Subversion 自身就通過"屬性"來存儲一些特殊的信息。一個使用Subversion
元數(shù)據(jù)的例子：可以在一些批處理的腳本程序或Subversion的鉤子程序（hooks）中創(chuàng)建、訪問、修改"屬性"元數(shù)據(jù)來滿足流程自動化的要求。
               
               
               

本文來自ChinaUnix博客，如果查看原文請點：http://blog.chinaunix.net/u/16651/showart_2056021.html