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

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

一、Subversion包含絕大部分CVS功能

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

二、全局性的版本編號

一個(gè)新的版本，并得到一個(gè)自增量的版本號N+1，該版本號并不針對某個(gè)特定的文件，而是全局性的、針對整個(gè)版本庫的。因此，我們可以將Subversion的版本庫看作是一個(gè)文件系統(tǒng)或文件目錄樹的數(shù)組。從技術(shù)的角度來說，在Subversion中，“文件foo.c的第5版本”這個(gè)說法是錯(cuò)誤的;正確的說法應(yīng)該是：”文件foo.c在版本庫被修改了5次，即執(zhí)行5次commit后是什么樣子?”。顯然，在Subversion中，版本庫被修改5次后foo.c的內(nèi)容，和被修改了6次后foo.c的內(nèi)容很可能完全一樣，因?yàn)榘姹編斓牡?次修改很可能只修改了版本庫的其他部分，而并沒有對foo.c的進(jìn)行修改。相反，在CVS中，文件foo.c的第1.1版本和第1.2版本總是不同的。

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

三、目錄的版本控制

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

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

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

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

四、原子性提交

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

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

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

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

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

【編輯推薦】

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