本文主要介紹分析一下SVN與CVS優缺點，CVS和SVN的比較類似與比較C++和Java，很明顯CVS和SVN都遠比SourceSafe強大的多，如同C++和Java比Basic強大的多。CVS代表了幾乎代碼控制系統的所有功能項，盡管有時他的實現并不很方便。SVN,修正并添加了一些CVS并不擁有功能。例如，創建標志和分支dubious，你在編輯文件是其他人不會有任何通知。這有點象Java的發明者：他們認為你不需要指針他們就在Java里面取消了指針，Java里也沒有操作符重載。
編號對比項

CVS與SVN

1.SVN與CVS存儲類型格式
CVS是個基于RCS文件的版本控制系統。每個CVS文件都不過是普通的文件，加上一些額外信息。這些文件會簡單的重復本地文件的樹結構。因此，不必擔心有什么數據損失，如果必要的話你可以手工修改RCS文件。SVN是基于關系數據庫的(BerkleyDB)或一系列二進制文件的(FS_FS)。一方面這解決了許多問題(例如，并行讀寫共享文件)以及添加了許多新功能(例如運行時的事務特性。)。然而另一方面，數據存儲由此變得不透明，或是說并不那么用戶友好了。那就是為什么工具軟件，對倉庫(數據庫)變得那么重要了。

2.SVN與CVS速度
CVS比較慢。整體而言,由于架構實現的不同,SVN的確比CVS快很多。在網絡上它只傳輸很少的信息并支持更多的離線模式的功能。但這也是有代價的。速度的代價就是巨大的存儲（完全備份所有的工作文件）。

3.SVN與CVS標志&分支(!!!重要)
在我們看來，這些實現是適宜的。SVN開發員自認為把采用標志和分支而拋棄了其他三件東西是件了不起的事。實際上這意味著他們把這個概念替換為在檔案庫內部復制文件或目錄以便保存日志。這樣一來，無論標志創建還是分支創建都只是倉庫內部的文件復制了。在SVN的開發員看來，這是個很優雅的決策，這讓生活變得如此簡便。而我們看來，這絲毫沒有什么值得驕傲之處。對分支而言，事情還不怎么糟糕，現在分支不過是在倉庫內部的一個單獨的目錄而已了，不象早期還有些什么交錯。對標志而言，事情就不那么妙了。你已經不能對代碼加標志了，這個功能就這么沒了。在某種程度上說，SVN全文件編號補足了這個缺陷，SVN里整個倉庫都有版本號，但不是針對單個文件。當然，如果你認為一個符號標志比一個四位編碼有效的話，我們業無話可說。

4.SVN與CVS元數據
CVS只允許存儲文件。SVN允許一個文件有任意都的可命名屬性。功能十分完全，但不知到有什么用。#p#

5.SVN與CVS文件類型
CVS最初是為文本文件存儲而設計的。因此其他文件類型（二進制，統一碼）文件的支持幾乎沒有，如需要的話則要有其他信息，并且客戶端服務器端都要調整。SVN會關心所有的文件類型，不需要你來手工操作。

6.SVN與CVS滾回
CVS允許任意的滾回，在任意一個已遞交的版本上，盡管著要花些時間（所有的文件都要分別處理）。SVN不允許遞交后滾回。我們建議把倉庫里好的狀態版本加到末尾，覆蓋掉損壞的版本。而損壞的版本無論如何也是會存在數據庫里的。（svn的滾回操作實際上是merge操作）.

7.SVN與CVS事務
CVS中的“零或一”事務原則根本沒有實現。如果檢入幾個文件的話（加到服務器上），很有可能部分文件完成了，而另幾個沒有。做為一個潛規則，手工糾正這些并且對余下的文件(而不是所有文件)一一重復檢入。這樣這些文件將在兩階段中被檢入。但至今為止，因為這個功能缺少而導致的數據倉庫損壞的案例還沒有出現過。SVN的確支持“零或一”事務原則，這是SVN的一大優勢。

8.SVN與CVS可用性
CVS可以用在你需要的地方，支持完善。SVN并未廣泛運用，一些支持項目仍然沒有實現。

SVN并不是CVS的替代品。他只是個不同的系統，類似于CVS。它有些特有的功能，足以作為采用它的理由。這些功能使他更適合于開發環境，例如對PowerBuilder。下面你可以找到兩者的相對優勢、劣勢。我們假設余下的東西兩者沒有什么大差別。如果你對兩者都舉棋不定，我們建議試試兩個系統，注意觀察下面幾個指標。你也可以到網上看看兩者之間的討論。

注意：這份評價表并不代表最終意見，兩個系統仍然在開發之中。

  【編輯推薦】

1. 軟件測試的配置管理從CVS遷移到SVN
2. CentOS系統中安裝subversion并使用svn+ssh訪問
3. 基于Java的svn客戶端工具JavaSVN 1.1.0.beta發布
4. 如何結合使用Subversion和Eclipse
5. Subversion日期解析函數緩沖區溢出漏洞