本節(jié)向大家簡(jiǎn)單介紹一下SVN功能和CVS功能比較，主要包括七個(gè)方面，在這里和大家分享一下，希望通過本節(jié)的學(xué)習(xí)你對(duì)SVN功能和CVS功能的不同之處有所了解，下面是SVN功能和CVS功能的具體介紹。

SVN與CVS的對(duì)比——功能性對(duì)比
一、SVN包含絕大部分CVS功能
SVN作為CVS的重寫版和改進(jìn)版，其目標(biāo)就是作為一個(gè)更好的版本控制軟件，取代目前流行的CVS。SVN功能的主要開發(fā)人員都是業(yè)界知名的CVS專家。SVN支持絕大部分的CVS功能/命令；SVN的命令風(fēng)格和界面也與CVS非常接近。當(dāng)然，不同的地方正是對(duì)CVS的改進(jìn)。
二、全局性的版本編號(hào)
一個(gè)新的版本，并得到一個(gè)自增量的版本號(hào)N+1，該版本號(hào)并不針對(duì)某個(gè)特定的文件，而是全局性的、針對(duì)整個(gè)版本庫(kù)的。因此，我們可以將SVN的版本庫(kù)看作是一個(gè)文件系統(tǒng)或文件目錄樹的數(shù)組。
從技術(shù)的角度來(lái)說(shuō)，在SVN功能中，“文件foo.c的第5版本”這個(gè)說(shuō)法是錯(cuò)誤的；正確的說(shuō)法應(yīng)該是：”文件foo.c在版本庫(kù)被修改了5次，即執(zhí)行5次commit后是什么樣子？”。顯然，在SVN中，版本庫(kù)被修改5次后foo.c的內(nèi)容，和被修改了6次后foo.c的內(nèi)容很可能完全一樣，因?yàn)榘姹編?kù)的第6次修改很可能只修改了版本庫(kù)的其他部分，而并沒有對(duì)foo.c的進(jìn)行修改。相反，在CVS中，文件foo.c的第1.1版本和第1.2版本總是不同的。
SVN的全局性版本編號(hào)為SVN帶來(lái)了諸多的優(yōu)勢(shì)：如對(duì)目錄或文件執(zhí)行拷貝，無(wú)論涉及多少文件，SVN不需要對(duì)單個(gè)文件依次執(zhí)行拷貝命令，僅僅需要建立一個(gè)指向相應(yīng)的全局版本號(hào)的一個(gè)指針即可。
三、目錄的版本控制
CVS只能對(duì)文件進(jìn)行版本控制，不能對(duì)目錄進(jìn)行版本控制，因此CVS沒有任何關(guān)于文件“移動(dòng)”（move）操作的概念。當(dāng)人為進(jìn)行文件移動(dòng)操作時(shí)，CVS只能注意到，一個(gè)文件在一個(gè)位置被刪除了，而在一個(gè)新位置創(chuàng)建了另外一個(gè)文件。由于它不會(huì)連接兩個(gè)操作，因此也很容易使文件歷史軌跡丟失。設(shè)置CVS存儲(chǔ)庫(kù)時(shí)，必須非常謹(jǐn)慎地為每個(gè)文件選擇準(zhǔn)確的位置，因?yàn)樵谠O(shè)置之后，幾乎就要一直使用這個(gè)位置了。
同樣由于CVS不記錄目錄的版本歷史，CVS不支持對(duì)文件的“重命名”（rename），人為的對(duì)文件進(jìn)行重命名會(huì)使得命名前后的文件失去歷史聯(lián)系，而記錄歷史本來(lái)是版本管理的主要目的。
還有，CVS不支持對(duì)文件的“拷貝”（copy），人為的拷貝對(duì)CVS而言，只能看到新的文件的增加，而不能記錄拷貝源文件和目標(biāo)文件之間的聯(lián)系。
綜上所述，缺乏對(duì)文件“移動(dòng)”、“重命名”、“拷貝”的支持的根源在于CVS不能記錄目錄的版本歷史，而這些操作在當(dāng)前的軟件開發(fā)過程中經(jīng)常發(fā)生，這正是SVN被開發(fā)并取代CVS的主要原因之一。
SVN將目錄作為一類特殊的文件來(lái)處理（事實(shí)上，從文件系統(tǒng)的角度來(lái)看，目錄確實(shí)是一類特殊的文件，當(dāng)目錄中的子目錄/文件被刪除、重命名、或新的子目錄/文件被創(chuàng)建時(shí)，目錄的內(nèi)容將發(fā)生改變）。因此，SVN象記錄普通文件的修改歷史一樣記錄對(duì)目錄的修改歷史，當(dāng)發(fā)生文件/目錄的移動(dòng)、重命名或拷貝操作時(shí)，SVN能夠準(zhǔn)確記錄操作前后的歷史聯(lián)系。同樣，象對(duì)文件的不同歷史版本進(jìn)行比較一樣，SVN支持對(duì)目錄的不同歷史版本的比較，清晰展現(xiàn)目錄的變化歷史。
四、原子性提交
從使用者的角度來(lái)看，CVS和SVN功能都支持對(duì)多個(gè)文件修改的批量提交，但二者在實(shí)現(xiàn)方式上存在本質(zhì)的區(qū)別。
CVS采用線性、串行的批量提交，即依次地，一個(gè)接一個(gè)地執(zhí)行提交，每成功提交一個(gè)文件，該文件的一個(gè)新的版本即被記錄到版本庫(kù)中，提交時(shí)用戶提供的日志信息被重復(fù)地存儲(chǔ)到每一個(gè)被修改的文件的版本歷史中。
CVS串行批量提交模式的弊端在于－當(dāng)任何原因造成批量操作的中斷時(shí)（典型原因包括：網(wǎng)絡(luò)中斷、客戶端死機(jī)等），版本庫(kù)往往處于一個(gè)不一致的狀態(tài)：原本應(yīng)該全部入庫(kù)的文件只有一部分入庫(kù)，很有可能版本庫(kù)中的***版本不能順利編譯，更為嚴(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í)也會(huì)造成不一致：假設(shè)用戶A啟動(dòng)一個(gè)需要較長(zhǎng)時(shí)間才能完成的批量提交；與此同時(shí)，用戶B執(zhí)行cvsupdate操作。此時(shí)，用戶B很有可能得到一個(gè)不一致的更新，即用戶B通過“更新”操作，得到用戶A的部分修改文件。
SVN徹底消除了CVS的以上弊端。無(wú)論批量提交包含多少文件修改，只有當(dāng)全部文件修改都成功入庫(kù)，該提交才變得有效，才對(duì)其他用戶可見；否則，無(wú)論任何原因造成中斷，SVN都會(huì)自動(dòng)執(zhí)行“回滾”（rollback）操作。換一個(gè)說(shuō)法，SVN保證所有的修改要么全部入庫(kù)生效，要么一個(gè)也不入庫(kù)，即對(duì)版本庫(kù)不作任何的修改。這就是SVN的原子性提交（atomiccommit）。
由于SVN的原子性提交特性和全局版本編號(hào)方式，當(dāng)提交成功完成時(shí)，一個(gè)唯一的、新的全局版本編號(hào)產(chǎn)生，而提交時(shí)用戶提供的日志信息與該新的版本編號(hào)關(guān)聯(lián)，只進(jìn)行一次存儲(chǔ)（區(qū)別于CVS的按文件重復(fù)存儲(chǔ)）。
五、支持變更集概念
由于SVN功能中所有提交是原子性的，每次成功提交形成的唯一的全局版本號(hào)對(duì)應(yīng)此次批量提交的所有文件修改，也就是說(shuō)，一個(gè)SVN版本號(hào)其實(shí)對(duì)應(yīng)了一個(gè)邏輯上的變更集（changeset），該變更集可能對(duì)應(yīng)于對(duì)一個(gè)BUG的修復(fù)，或者對(duì)應(yīng)于對(duì)一個(gè)已有功能的改進(jìn)，或者對(duì)應(yīng)于一個(gè)新功能的實(shí)現(xiàn)?？梢哉f(shuō)，變更集是一個(gè)軟件開發(fā)活動(dòng)的邏輯結(jié)果，該變更集可以通過其對(duì)應(yīng)的版本號(hào)在軟件開發(fā)的其他過程中（如軟件合并/集成過程，軟件發(fā)布管理，變更管理系統(tǒng)，缺陷追蹤系統(tǒng)）被引用。因此，SVN將版本管理從單純的、單個(gè)的文件修改的層次通過邏輯上的抽象，上升到更便于理解和交流的開發(fā)活動(dòng)的層次。
六、差異化的二進(jìn)制文件處理
由于歷史原因，CVS主要是為早期的程序員設(shè)計(jì)的，CVS能夠有效處理文本文件（或ASCII文件，源代碼文件），可以對(duì)文本文件進(jìn)行差異化的存儲(chǔ)、新舊版本的比較，文件合并等；但對(duì)于二進(jìn)制文件，CVS則明顯力不從心。在CVS的版本庫(kù)中，對(duì)于二進(jìn)制文件的歷史版本，CVS唯一能做的就是對(duì)不同的版本進(jìn)行獨(dú)立的、冗余的存儲(chǔ)，哪怕版本之間其實(shí)只存在微小的差異。舉例而言，一個(gè)10M的二進(jìn)制文件（照片、圖形文件、機(jī)械設(shè)計(jì)文件、電子設(shè)計(jì)文件）假如每周修改一次，無(wú)論每次修改的大小，一年下來(lái)，僅該文件就要消耗500M以上的存儲(chǔ)空間。而且，客戶端每次獲取該文件的新版本都要消耗10M的網(wǎng)絡(luò)流量。
對(duì)于目前的開發(fā)團(tuán)隊(duì)，無(wú)論是軟件開發(fā)，Web站點(diǎn)的開發(fā)，手機(jī)等電子產(chǎn)品的研發(fā)，需要進(jìn)行版本管理的不僅是源代碼等文本文件，還需要管理需求文檔、設(shè)計(jì)文檔、測(cè)試文檔、用戶手冊(cè)，圖形圖像文件，機(jī)械/電子設(shè)計(jì)文件等諸多的二進(jìn)制文件，CVS顯然不是一個(gè)好的選擇。
與CVS不同，SVN采用統(tǒng)一的二進(jìn)制差異算法（binarydifferencingalgorithm），即對(duì)文本文件和二進(jìn)制文件采用相同的差異比較算法，并以相同的方式在版本庫(kù)中進(jìn)行存儲(chǔ)：每次提交后版本庫(kù)中只存儲(chǔ)相對(duì)于先前版本的差異，從而可以節(jié)省大量的存儲(chǔ)空間。
該二進(jìn)制差異算法不僅應(yīng)用在版本的存儲(chǔ)上，更為重要的是，SVN對(duì)二進(jìn)制文件與文本文件一視同仁，當(dāng)客戶端需要獲取新的版本時(shí)（如執(zhí)行svnupdate），在網(wǎng)絡(luò)上只有版本的差異被傳輸，從而大大減少對(duì)網(wǎng)絡(luò)帶寬的消耗。更多細(xì)節(jié)參見“七、雙向的差異化－壓縮網(wǎng)絡(luò)傳輸”。SVN功能和CVS功能對(duì)比介紹中差異化的二進(jìn)制文件處理講解完畢。
七、雙向的差異化－壓縮網(wǎng)絡(luò)傳輸
如上所述，CVS對(duì)二進(jìn)制文件不能進(jìn)行有效的差異化處理。對(duì)于文本文件，CVS功能僅僅支持單向的差異化傳輸：從CVS服務(wù)器到客戶端的傳輸是差異化的，即執(zhí)行cvsupdate時(shí)，只有差異的部分從服務(wù)器傳輸?shù)娇蛻舳耍欢?dāng)執(zhí)行cvscommit時(shí)，無(wú)論代碼變化多少，CVS都需要從客戶端向服務(wù)器完整傳輸被修改文件的全部?jī)?nèi)容，不能只傳輸差異。
相反，無(wú)論是文本文件還是二進(jìn)制文件，SVN都進(jìn)行雙向的差異化傳輸，并且差異化內(nèi)容還要進(jìn)行壓縮/解壓縮的過程：在服務(wù)器端獲取差異顯而易見，與CVS類似；SVN在客戶端獲取差異的秘密在于—SVN在客戶端的工作拷貝中隱含了每個(gè)文件的一個(gè)“只讀的、干凈的”副本（該副本隱藏在隱含目錄.svn里，通常不可見，該副本還有更多的妙用，參見“十二、更多的本地/離線操作”），通過比較用戶在客戶端的修改和該隱含的副本，SVN獲取需要真正傳送到服務(wù)器的差異，并對(duì)差異進(jìn)行壓縮后才進(jìn)行網(wǎng)絡(luò)傳輸。
對(duì)CVS而言，操作的成本（網(wǎng)絡(luò)帶寬消耗是***的操作成本）與被修改的文件的大小成比例，而與修改本身的大小無(wú)關(guān)；對(duì)SVN而言，操作成本只與修改本身的大小成比例，而與被修改的文件的大小無(wú)關(guān)。因此，與CVS相比，SVN消耗更少的網(wǎng)絡(luò)帶寬（以客戶端的存儲(chǔ)空間換取更少的帶寬消耗在目前的計(jì)算環(huán)境下應(yīng)該是個(gè)相當(dāng)不錯(cuò)的選擇?。?。SVN更加適合基于互聯(lián)網(wǎng)（或廣域網(wǎng)）進(jìn)行協(xié)作開發(fā)的地理上分布的團(tuán)隊(duì)——版本服務(wù)器集中、單一；客戶端廣泛分布。請(qǐng)期待下節(jié)關(guān)于SVN功能和CVS功能對(duì)比介紹。

【編輯推薦】

1. 七步輕松實(shí)現(xiàn)搭建SVN服務(wù)端
2. 深入剖析opensuse10.3上如何搭建SVN服務(wù)器
3. 學(xué)習(xí)指導(dǎo) 如何搭建SVN服務(wù)器
4. 專家在線指導(dǎo)如何搭建SVN服務(wù)
5. 常用SVN目錄結(jié)構(gòu)使用的兩大方法詳解