VSS、CVS、SVN和ClearCase等配置工具的評估和比較
1
概述
Visual SourceSafe：微軟的版本控制工具，僅支持Windows操作系統。雖然簡單好用，但是僅適用於團隊級開發，不能勝任企業級的開發工作。
Clearcase：IBM旗下Rational公司(2003年被IBM收購)的一款重量級的軟件配置管理(SCM， SoftwareConfiguration Managemen)工具。與CVS和VSS不同，Clearcase涵蓋的範圍包括版本控制、建立管理、工作空間管理和過程控制。從最初的軟件配置計劃，到配置項的確立，從變更控制到版本控制，Clearcase貫穿於整個軟件生命週期。 Clearcase支持現有的絕大多數操作系統，但它的安裝、配置、使用相對較複雜，並且需要進行團隊培訓。
CVS：Concurrent Versions System。CVS 是有着三十年以上的時間的考驗。CVS是開放源代碼軟件世界的一個偉大傑作，由於CVS功能強大，跨平臺，支持併發版本控制，而且免費，所以它在全球中小型軟件企業中得到了廣泛使用。CVS最大的遺憾就是缺少相應的技術支持，許多問題的解決需要自已尋找資料，甚至是研究源代碼。CVS是一個典型的服務器/客戶端軟件，有UNIX版本的CVS 、Linux版本的CVS和WINDOWS版本的CVS。CVS支持遠程管理，項目組分佈開發時一般都採用CVS。
SVN：Subversion。採用了更先進的分支管理系統，它的設計目標就是取代CVS，CVS縱然易用，但也有一些與生俱來的缺點，比如CVS不支持文件改名，只對文件控制版本而沒有針對目錄的管理等。之後CVS 的創始人之一在其現任公司的資助下開發了SVN，用以針對CVS 的一些弱點進行改進。
2
主要功能說明CVS縱然是一個老牌的工具產品，並也對開源事業有貢獻，但CVS的命令行操作着實讓一些使用者頭疼。在對一個特定版本的文檔Check in的時候，需要輸入一長串的路徑名、文件名。在操作易用性上與CVS形成對比的是微軟家族的VSS。作爲微軟的產品，在圖形界面化操作上自不用多言，但VSS只能適用於小團隊的開發工作。VSS是很好的入門級工具，但它的一些功能太過於“入門”，在驗證密碼、保存密碼這些基本功能上處理的不盡人意。適用於大型軟件開發的有“中堅級”的Clearcase，用它來管理一些小型的項目管理有些“大材小用”。Clearcase支持目錄版本管理、異地團隊開發、視圖、多服務器等強大功能，所以一些大公司把它做爲一、二級產品管理用，但同樣它的價格也不菲。CVS是開源的，免費的，更何況它還有一個理想的替代者——SVN。SVN的設計專門針對CVS的問題作了改進,命令的設計更爲合理,對二進制文檔和目錄這樣的數據加強了控制能力,並且吸收了VSS的lock-modify-update(release)的模式和modify-merge模式的優點這兩種方式在一定程度都支持並作了優化,沒有提高使用的複雜度。由於SVN的設計結構很好,所以很容易爲它開發客戶端,還有WEB模式的,可以遠程管理,支持RSS更改訂閱。
功能
名稱
Internet網絡和遠程管理
並行開發
跨平臺開發
操作的便利性
信息安全性
VSS
最新發布版本VSS8.0可支持此功能
最新發布版本VSS8.0支持此功能
僅支持Windows 操作系統
安裝、配置、使用均較簡單，很容易上手使用
安全性不高，基於文件系統共享實現對服務器的訪問，需要共享存儲目錄，這樣用戶可以對VSS的文件夾執行刪除操作。
CVS
支持，速度一般
支持
支持幾乎所有的操作系統
安裝、配置較複雜，但使用比較簡單，只需對配置管理做簡單培訓即可
安全性高，CVS服務器有自己專用的數據庫，文件存儲並不採用 “共享目錄”方式，所以不受限於局域網。
SVN
相比CVS，更加適合基於互聯網協作開發的團隊，速度也更快
相比CVS，能夠保證所有的修改都入庫生效
同上
同上
同上
ClearCase
速度最快，且不受網絡連接帶寬的限制、防火牆以及安全問題的影響。
支持
支持常見的平臺
安裝、配置、使用相對較複雜，需要進行團隊培訓
安全性不高，採用C/S模式，需要共享服務器上的存儲目錄以供客戶端訪問
2.1
Internet網絡訪問和遠程管理
VSS、CVS和SVN都提供基於Web的界面，用戶可以通過瀏覽器執行配置管理的相關操作，即通過這樣的方法來實現對異地開發的支持。但是相對於CVS，SVN採用統一的二進制差異算法，所以消耗更少的網絡帶寬，因此更加適合基於互聯網（或廣域網）進行協作開發的地理上分佈的團隊，即版本服務器集中、單一；客戶端可廣泛分佈。
其實上述實現方法有太多的侷限性，例如網絡（Internet）連接帶寬的限制、防火牆以及安全問題等。真正意義上的異地開發支持，是指在不同的開發地點建立各自的存儲庫，通過工具提供同步功能自動或手動同步。這樣做的好處是與網絡無關，即便各個開發地點之間沒有實時連通的網絡，也可以通過E-Mail 附件等其它方式將同步包發給對方，實現手動的同步。而ClearCase就能實現這樣的功能。
值得說明的是，在不同開發點建立各自存儲庫的方式，主要適用於兩個或兩個以上位於不同地點的開發團隊協作開發的情況。如果僅是採用虛擬團隊合作的方式，開發人員以個體的形式散落在不同地方，則更適合通過Internet 直接操作遠程的配置管理服務器。
2.2
並行開發支持
在團隊協作開發過程中，有兩種主要的模式：集體代碼權和個體代碼權。採用集體代碼權模式進行開發時，一段代碼可能同時會被多個開發人員同時修改；而採用個體代碼權模式進行開發時，每一段代碼都始終被一個開發人員獨享，別人需要修改時也要通過該開發人員完成。
而配置管理軟件針對這一情況，也採用了不同的策略：Copy-Modify-Merge(拷貝、修改、合併)的並行開發模式、Check ut-Modify-Check in（簽出、修改、簽入）的獨佔開發模式。在並行開發模式下，開發人員可以並行開發、更改代碼，並能夠自動檢測到代碼衝突，並自動合併，或提示開發人員手動解決。
VSS最新發布版本8.0可支持並行開發模式，其它三種工具也都可支持。
CVS 採用線性、串行的批量提交，即依次地，一個接一個地執行提交，每成功提交一個文件，該文件的一個新的版本即被記錄到版本庫中，提交時用戶提供的日誌信息被重複地存儲到每一個被修改的文件的版本歷史中。但是當任何原因造成批量操作的中斷時（典型原因包括：網絡中斷、客戶端死機等），版本庫往往處於一個不一致的狀態：原本應該全部入庫的文件只有一部分入庫，很有可能版本庫中的最新版本不能順利編譯，更爲嚴重的是，隨着其他的用戶執行cvs update 操作，該不一致性將迅速在開發團隊中擴散，從而嚴重影響團隊的開發效率，並存在質量隱患。另外，假如該批量提交的中斷沒有被及時發現，開發團隊往往要花更多的時間進行軟件調試和排錯。
SVN徹底消除了CVS的以上弊端。無論批量提交包含多少文件修改，只有當全部文件修改都成功入庫，該提交才變得有效，纔對其他用戶可見；否則，無論任何原因造成中斷，SVN 都會自動執行“回滾”（rollback）操作。換一個說法，SVN保證所有的修改要麼全部入庫生效，要麼一個也不入庫，即對版本庫不作任何的修改。這就是SVN 的原子性提交（atomic commit）。
ClearCase可以很容易的產生分支，也可以很容易的將不同分支進行合併。這樣一來，即便某一部分的工作被凍結或加鎖，開發者仍然可以繼續自己的工作（如：在軟件集成期）。在這種情況，開發者可以在分支上工作，ClearCase的自動化操作和圖形歸併工具可以很容易的重新集成新的工作。
2.3
跨平臺開發支持
如果企業需要從事多個不同平臺下的開發工作，就需要配置管理工具能夠對跨平臺開發提供支持，否則勢必會給開發、測試、發佈等各個環節帶來不便，將使大量的時間被浪費於代碼的手工上傳、下載中。
VSS僅支持Windows操作系統。
CVS、SVN和ClearCase支持幾乎所有的操作系統和平臺。但是CVS和SVN的服務器端在Unix, Linux環境下運行會更穩定可靠。
2.4
開發操作使用的便利性VSS安裝、配置、使用均較簡單，很容易上手使用。
CVS和SVN安裝、配置較複雜，但使用比較簡單，只需對配置管理做簡單培訓即可。
ClearCase安裝、配置、使用相對較複雜，需要進行團隊培訓，需投入成本大概四萬元。
2.5
信息安全性VSS它是基於文件系統共享實現對服務器的訪問，需要共享存儲目錄，這樣用戶可以對VSS的文件夾執行刪除操作，安全性不高。
CVS和SVN服務器有自己專用的數據庫，文件存儲並不採用 “共享目錄”方式，所以不受限於局域網。安全性較高。
ClearCase採用C/S模式，需要共享服務器上的存儲目錄以供客戶端訪問，安全性不高。
概述
Visual SourceSafe：微軟的版本控制工具，僅支持Windows操作系統。雖然簡單好用，但是僅適用於團隊級開發，不能勝任企業級的開發工作。
Clearcase：IBM旗下Rational公司(2003年被IBM收購)的一款重量級的軟件配置管理(SCM， SoftwareConfiguration Managemen)工具。與CVS和VSS不同，Clearcase涵蓋的範圍包括版本控制、建立管理、工作空間管理和過程控制。從最初的軟件配置計劃，到配置項的確立，從變更控制到版本控制，Clearcase貫穿於整個軟件生命週期。 Clearcase支持現有的絕大多數操作系統，但它的安裝、配置、使用相對較複雜，並且需要進行團隊培訓。
CVS：Concurrent Versions System。CVS 是有着三十年以上的時間的考驗。CVS是開放源代碼軟件世界的一個偉大傑作，由於CVS功能強大，跨平臺，支持併發版本控制，而且免費，所以它在全球中小型軟件企業中得到了廣泛使用。CVS最大的遺憾就是缺少相應的技術支持，許多問題的解決需要自已尋找資料，甚至是研究源代碼。CVS是一個典型的服務器/客戶端軟件，有UNIX版本的CVS 、Linux版本的CVS和WINDOWS版本的CVS。CVS支持遠程管理，項目組分佈開發時一般都採用CVS。
SVN：Subversion。採用了更先進的分支管理系統，它的設計目標就是取代CVS，CVS縱然易用，但也有一些與生俱來的缺點，比如CVS不支持文件改名，只對文件控制版本而沒有針對目錄的管理等。之後CVS 的創始人之一在其現任公司的資助下開發了SVN，用以針對CVS 的一些弱點進行改進。
2
主要功能說明CVS縱然是一個老牌的工具產品，並也對開源事業有貢獻，但CVS的命令行操作着實讓一些使用者頭疼。在對一個特定版本的文檔Check in的時候，需要輸入一長串的路徑名、文件名。在操作易用性上與CVS形成對比的是微軟家族的VSS。作爲微軟的產品，在圖形界面化操作上自不用多言，但VSS只能適用於小團隊的開發工作。VSS是很好的入門級工具，但它的一些功能太過於“入門”，在驗證密碼、保存密碼這些基本功能上處理的不盡人意。適用於大型軟件開發的有“中堅級”的Clearcase，用它來管理一些小型的項目管理有些“大材小用”。Clearcase支持目錄版本管理、異地團隊開發、視圖、多服務器等強大功能，所以一些大公司把它做爲一、二級產品管理用，但同樣它的價格也不菲。CVS是開源的，免費的，更何況它還有一個理想的替代者——SVN。SVN的設計專門針對CVS的問題作了改進,命令的設計更爲合理,對二進制文檔和目錄這樣的數據加強了控制能力,並且吸收了VSS的lock-modify-update(release)的模式和modify-merge模式的優點這兩種方式在一定程度都支持並作了優化,沒有提高使用的複雜度。由於SVN的設計結構很好,所以很容易爲它開發客戶端,還有WEB模式的,可以遠程管理,支持RSS更改訂閱。
功能
名稱
Internet網絡和遠程管理
並行開發
跨平臺開發
操作的便利性
信息安全性
VSS
最新發布版本VSS8.0可支持此功能
最新發布版本VSS8.0支持此功能
僅支持Windows 操作系統
安裝、配置、使用均較簡單，很容易上手使用
安全性不高，基於文件系統共享實現對服務器的訪問，需要共享存儲目錄，這樣用戶可以對VSS的文件夾執行刪除操作。
CVS
支持，速度一般
支持
支持幾乎所有的操作系統
安裝、配置較複雜，但使用比較簡單，只需對配置管理做簡單培訓即可
安全性高，CVS服務器有自己專用的數據庫，文件存儲並不採用 “共享目錄”方式，所以不受限於局域網。
SVN
相比CVS，更加適合基於互聯網協作開發的團隊，速度也更快
相比CVS，能夠保證所有的修改都入庫生效
同上
同上
同上
ClearCase
速度最快，且不受網絡連接帶寬的限制、防火牆以及安全問題的影響。
支持
支持常見的平臺
安裝、配置、使用相對較複雜，需要進行團隊培訓
安全性不高，採用C/S模式，需要共享服務器上的存儲目錄以供客戶端訪問
2.1
Internet網絡訪問和遠程管理
VSS、CVS和SVN都提供基於Web的界面，用戶可以通過瀏覽器執行配置管理的相關操作，即通過這樣的方法來實現對異地開發的支持。但是相對於CVS，SVN採用統一的二進制差異算法，所以消耗更少的網絡帶寬，因此更加適合基於互聯網（或廣域網）進行協作開發的地理上分佈的團隊，即版本服務器集中、單一；客戶端可廣泛分佈。
其實上述實現方法有太多的侷限性，例如網絡（Internet）連接帶寬的限制、防火牆以及安全問題等。真正意義上的異地開發支持，是指在不同的開發地點建立各自的存儲庫，通過工具提供同步功能自動或手動同步。這樣做的好處是與網絡無關，即便各個開發地點之間沒有實時連通的網絡，也可以通過E-Mail 附件等其它方式將同步包發給對方，實現手動的同步。而ClearCase就能實現這樣的功能。
值得說明的是，在不同開發點建立各自存儲庫的方式，主要適用於兩個或兩個以上位於不同地點的開發團隊協作開發的情況。如果僅是採用虛擬團隊合作的方式，開發人員以個體的形式散落在不同地方，則更適合通過Internet 直接操作遠程的配置管理服務器。
2.2
並行開發支持
在團隊協作開發過程中，有兩種主要的模式：集體代碼權和個體代碼權。採用集體代碼權模式進行開發時，一段代碼可能同時會被多個開發人員同時修改；而採用個體代碼權模式進行開發時，每一段代碼都始終被一個開發人員獨享，別人需要修改時也要通過該開發人員完成。
而配置管理軟件針對這一情況，也採用了不同的策略：Copy-Modify-Merge(拷貝、修改、合併)的並行開發模式、Check ut-Modify-Check in（簽出、修改、簽入）的獨佔開發模式。在並行開發模式下，開發人員可以並行開發、更改代碼，並能夠自動檢測到代碼衝突，並自動合併，或提示開發人員手動解決。
VSS最新發布版本8.0可支持並行開發模式，其它三種工具也都可支持。
CVS 採用線性、串行的批量提交，即依次地，一個接一個地執行提交，每成功提交一個文件，該文件的一個新的版本即被記錄到版本庫中，提交時用戶提供的日誌信息被重複地存儲到每一個被修改的文件的版本歷史中。但是當任何原因造成批量操作的中斷時（典型原因包括：網絡中斷、客戶端死機等），版本庫往往處於一個不一致的狀態：原本應該全部入庫的文件只有一部分入庫，很有可能版本庫中的最新版本不能順利編譯，更爲嚴重的是，隨着其他的用戶執行cvs update 操作，該不一致性將迅速在開發團隊中擴散，從而嚴重影響團隊的開發效率，並存在質量隱患。另外，假如該批量提交的中斷沒有被及時發現，開發團隊往往要花更多的時間進行軟件調試和排錯。
SVN徹底消除了CVS的以上弊端。無論批量提交包含多少文件修改，只有當全部文件修改都成功入庫，該提交才變得有效，纔對其他用戶可見；否則，無論任何原因造成中斷，SVN 都會自動執行“回滾”（rollback）操作。換一個說法，SVN保證所有的修改要麼全部入庫生效，要麼一個也不入庫，即對版本庫不作任何的修改。這就是SVN 的原子性提交（atomic commit）。
ClearCase可以很容易的產生分支，也可以很容易的將不同分支進行合併。這樣一來，即便某一部分的工作被凍結或加鎖，開發者仍然可以繼續自己的工作（如：在軟件集成期）。在這種情況，開發者可以在分支上工作，ClearCase的自動化操作和圖形歸併工具可以很容易的重新集成新的工作。
2.3
跨平臺開發支持
如果企業需要從事多個不同平臺下的開發工作，就需要配置管理工具能夠對跨平臺開發提供支持，否則勢必會給開發、測試、發佈等各個環節帶來不便，將使大量的時間被浪費於代碼的手工上傳、下載中。
VSS僅支持Windows操作系統。
CVS、SVN和ClearCase支持幾乎所有的操作系統和平臺。但是CVS和SVN的服務器端在Unix, Linux環境下運行會更穩定可靠。
2.4
開發操作使用的便利性VSS安裝、配置、使用均較簡單，很容易上手使用。
CVS和SVN安裝、配置較複雜，但使用比較簡單，只需對配置管理做簡單培訓即可。
ClearCase安裝、配置、使用相對較複雜，需要進行團隊培訓，需投入成本大概四萬元。
2.5
信息安全性VSS它是基於文件系統共享實現對服務器的訪問，需要共享存儲目錄，這樣用戶可以對VSS的文件夾執行刪除操作，安全性不高。
CVS和SVN服務器有自己專用的數據庫，文件存儲並不採用 “共享目錄”方式，所以不受限於局域網。安全性較高。
ClearCase採用C/S模式，需要共享服務器上的存儲目錄以供客戶端訪問，安全性不高。
性能詳述
3.1
VSS優點：操作簡單，容易掌握；權限劃分可到文件夾級，有Read、CheckOut&&CheckIn、Add/Rename/Delete、Destroy四種權限級別。
缺點：權限管理基於文件共享形式，只能從文件夾共享的權限設定對整個庫文件夾的權限，而且必須要有可寫權限；版本管理和分支管理只能靠人爲的手工設置；版本發行時，只能手工挑選對應的版本文件進行發佈。
最新版本VSS8.0主要增加了以下功能：
Ø
支持並行開發
Ø
支持基於Internet的遠程訪問模式
Ø
分佈式團隊協作增強
3.2
CVSCVS 誕生於 1986 年，當時作爲一組 shell腳本而出現；1989年3月，Brian Berlinor用C語言重新設計並編寫了CVS的代碼；1993年前後，Jim Kingdon最終將CVS設計成基於網絡的平臺，開發者們能從Internet任何地方獲得程序源代碼。截至目前最新版本是2004年12月13日發佈的
功能介紹
Ø
代碼統一管理，保存所有代碼文件更改的歷史記錄。對代碼進行集中統一管理，可以方便查看新增或刪除的文件，能夠跟蹤所有代碼改動痕跡。可以隨意恢復到以前任意一個歷史版本。並避免了因爲版本不同引入的深層BUG。
Ø
完善的衝突解決方案，可以方便的解決文件衝突問題，而不需要藉助其它的文件比較工具和手工的粘貼複製。
Ø
代碼權限的管理，可以爲不同的用戶設置不同的權限。可以設置訪問用戶的密碼、只讀、修改等權限，而且通過CVS ROOT目錄下的腳本，提供了相應功能擴充的接口，不但可以完成精細的權限控制，還能完成更加個性化的功能。
Ø
支持方便的版本發佈和分支功能。CVS在服務器端維護代碼文檔庫，不同的開發者在本地機器上建立對應代碼樹，並利用CVS保持本地代碼文檔同代碼文檔庫的一致。當由於多個開發者對文件的同時修改造成本地與庫中的代碼文件衝突時，CVS報告並協助解決衝突代碼的合併問題。普通開發者（非管理員）對CVS的使用流程。
3.3
SVN
SVN 是一個自由/開源版本控制系統，它管理文件和目錄可以超越時間。一組文件存放在中心版本庫，這個版本庫很像一個普通的文件服務器，只是它可以記錄每一次文件和目錄的修改，這便使你可以取得數據以前的版本，從而可以檢查所作的更改。從這個方面看，許多人把版本控制系統當作一種“時間機器”。
SVN 可以通過網絡訪問它的版本庫，從而使用戶可以在不同的電腦上使用。一定程度上可以說，允許用戶在各自的地方修改同一份數據是促進協作。由於所有的工作都有歷史版本，你不必擔心由於失去某個通道而影響質量，如果存在不正確的改變，只要取消改變。
SVN的歷史：
早在2000 年，CollabNet,Inc. (http://www.collab.net/) 開始尋找CVS 替代產品的開發人員，CollabNet 提供了一個協作軟件套件CEE (CollabNet EnterpriseEdition)，它的一個組件是版本控制系統。儘管CEE 在初始時使用CVS 作爲其版本控制系統，但是CVS 的侷限性在一開始就很明顯，CollabNet 知道遲早要找到一個更好的替代品。遺憾的是，CVS成爲了開源世界事實上的標準，因爲沒有更好的產品，至少是沒有可以自由使用的。所以CollabNet 決定寫一個新的版本控制系統，建立在CVS 思想之上的，但是修正其錯誤和不合理的特性。
2000 年2 月，他們聯繫OpenSource Development with CVS(Coriolis, 1999)的作者Karl Fogel，並且詢問他是否希望爲這個新項目工作，巧合的是，當時Karl 正在與朋友JimBlandy 討論設計一個新的版本控制系統。在1995 年，他們兩個曾經開辦一個提供CVS支持的公司Cyclic Software，儘管他們最終賣掉了公司，但還是天天使用CVS 進行日常工作，在使用CVS 時的挫折最終促使他們認真地去考慮如何管理標記版本的數據，而且他們當時不僅僅提出了“SVN”這個名字，並且做出了SVN 版本庫的基礎設計。所以當CollabNet 提出邀請的時候，Karl 馬上同意爲這個項目工作，同時Jim 也得到了他的僱主，RedHat 軟件贊助他到這個項目並提供了一個寬鬆的時間。CollabNet 僱傭了Karl 和Ben Collins Sussman，詳細的設計從三月開始，在Behlendorf 、CollabNet、Jason Robbins 和 Greg Stein（當時是一個獨立開發者，活躍在WebDAV/DeltaV 系統規範階段）的恰當激勵的幫助下，SVN 很快吸引了許多活躍的開發者，結果是許多有CVS 經驗的人們很樂於有機會爲這個項目做些事情。
最初的設計小組固定在簡單的目標上，他們不想在版本控制方法學中開墾處女地，他們只是希望修正CVS，他們決定SVN 匹配CVS 的特性，保留相同的開發模型，但不復制CVS 明顯的缺陷。儘管它不需要成爲CVS的繼任者，它也應該與CVS 保持足夠的相似性，使得CVS 用戶可以輕鬆的做出轉換。
經過14 個月的編碼，2001 年8 月31 日，SVN 自己能夠“成爲服務”了，開發者停止使用CVS 保存SVN 的代碼，而使用SVN 本身。
當CollabNet 開始這個項目的時候，曾經資助了大量的工作（它爲全職的SVN 開發者提供薪水），SVN 像許多開源項目一樣，被一些激勵知識界精英的寬鬆透明的規則支配着。CollabNet的版權許可證完全符合Debian的自由軟件方針，也就是說，任何人可以自由的下載，修改和重新發布，不需要經過CollabNet 或其他人的允許。
SVN和CVS功能性對比：
一、SVN包含絕大部分CVS功能
SVN 作爲CVS 的重寫版和改進版，其目標就是作爲一個更好的版本控制軟件，取代目前流行的CVS。SVN 的主要開發人員都是業界知名的CVS 專家。SVN支持絕大部分的CVS 功能/命令；SVN 的命令風格和界面也與CVS 非常接近。當然，不同的地方正是對CVS 的改進。
二、全局性的版本編號
一個新的版本，並得到一個自增量的版本號N+1，該版本號並不針對某個特定的文件，而是全局性的、針對整個版本庫的。因此，我們可以將SVN 的版本庫看作是一個文件系統或文件目錄樹的數組。
從技術的角度來說，在SVN 中，“文件foo.c 的第5 版本”這個說法是錯誤的；正確的說法應該是：”文件foo.c 在版本庫被修改了5 次，即執行5 次commit 後是什麼樣子？”。顯然，在SVN 中，版本庫被修改5 次後foo.c 的內容，和被修改了6 次後foo.c 的內容很可能完全一樣，因爲版本庫的第6 次修改很可能只修改了版本庫的其他部分，而並沒有對foo.c 的進行修改。相反，在CVS 中，文件foo.c 的第1.1 版本和第1.2 版本總是不同的。
SVN 的全局性版本編號爲SVN 帶來了諸多的優勢：如對目錄或文件執行拷貝，無論涉及多少文件，SVN 不需要對單個文件依次執行拷貝命令，僅僅需要建立一個指向相應的全局版本號的一個指針即可。
3.1
VSS優點：操作簡單，容易掌握；權限劃分可到文件夾級，有Read、CheckOut&&CheckIn、Add/Rename/Delete、Destroy四種權限級別。
缺點：權限管理基於文件共享形式，只能從文件夾共享的權限設定對整個庫文件夾的權限，而且必須要有可寫權限；版本管理和分支管理只能靠人爲的手工設置；版本發行時，只能手工挑選對應的版本文件進行發佈。
最新版本VSS8.0主要增加了以下功能：
Ø
支持並行開發
Ø
支持基於Internet的遠程訪問模式
Ø
分佈式團隊協作增強
3.2
CVSCVS 誕生於 1986 年，當時作爲一組 shell腳本而出現；1989年3月，Brian Berlinor用C語言重新設計並編寫了CVS的代碼；1993年前後，Jim Kingdon最終將CVS設計成基於網絡的平臺，開發者們能從Internet任何地方獲得程序源代碼。截至目前最新版本是2004年12月13日發佈的
功能介紹
Ø
代碼統一管理，保存所有代碼文件更改的歷史記錄。對代碼進行集中統一管理，可以方便查看新增或刪除的文件，能夠跟蹤所有代碼改動痕跡。可以隨意恢復到以前任意一個歷史版本。並避免了因爲版本不同引入的深層BUG。
Ø
完善的衝突解決方案，可以方便的解決文件衝突問題，而不需要藉助其它的文件比較工具和手工的粘貼複製。
Ø
代碼權限的管理，可以爲不同的用戶設置不同的權限。可以設置訪問用戶的密碼、只讀、修改等權限，而且通過CVS ROOT目錄下的腳本，提供了相應功能擴充的接口，不但可以完成精細的權限控制，還能完成更加個性化的功能。
Ø
支持方便的版本發佈和分支功能。CVS在服務器端維護代碼文檔庫，不同的開發者在本地機器上建立對應代碼樹，並利用CVS保持本地代碼文檔同代碼文檔庫的一致。當由於多個開發者對文件的同時修改造成本地與庫中的代碼文件衝突時，CVS報告並協助解決衝突代碼的合併問題。普通開發者（非管理員）對CVS的使用流程。
3.3
SVN
SVN 是一個自由/開源版本控制系統，它管理文件和目錄可以超越時間。一組文件存放在中心版本庫，這個版本庫很像一個普通的文件服務器，只是它可以記錄每一次文件和目錄的修改，這便使你可以取得數據以前的版本，從而可以檢查所作的更改。從這個方面看，許多人把版本控制系統當作一種“時間機器”。
SVN 可以通過網絡訪問它的版本庫，從而使用戶可以在不同的電腦上使用。一定程度上可以說，允許用戶在各自的地方修改同一份數據是促進協作。由於所有的工作都有歷史版本，你不必擔心由於失去某個通道而影響質量，如果存在不正確的改變，只要取消改變。
SVN的歷史：
早在2000 年，CollabNet,Inc. (http://www.collab.net/) 開始尋找CVS 替代產品的開發人員，CollabNet 提供了一個協作軟件套件CEE (CollabNet EnterpriseEdition)，它的一個組件是版本控制系統。儘管CEE 在初始時使用CVS 作爲其版本控制系統，但是CVS 的侷限性在一開始就很明顯，CollabNet 知道遲早要找到一個更好的替代品。遺憾的是，CVS成爲了開源世界事實上的標準，因爲沒有更好的產品，至少是沒有可以自由使用的。所以CollabNet 決定寫一個新的版本控制系統，建立在CVS 思想之上的，但是修正其錯誤和不合理的特性。
2000 年2 月，他們聯繫OpenSource Development with CVS(Coriolis, 1999)的作者Karl Fogel，並且詢問他是否希望爲這個新項目工作，巧合的是，當時Karl 正在與朋友JimBlandy 討論設計一個新的版本控制系統。在1995 年，他們兩個曾經開辦一個提供CVS支持的公司Cyclic Software，儘管他們最終賣掉了公司，但還是天天使用CVS 進行日常工作，在使用CVS 時的挫折最終促使他們認真地去考慮如何管理標記版本的數據，而且他們當時不僅僅提出了“SVN”這個名字，並且做出了SVN 版本庫的基礎設計。所以當CollabNet 提出邀請的時候，Karl 馬上同意爲這個項目工作，同時Jim 也得到了他的僱主，RedHat 軟件贊助他到這個項目並提供了一個寬鬆的時間。CollabNet 僱傭了Karl 和Ben Collins Sussman，詳細的設計從三月開始，在Behlendorf 、CollabNet、Jason Robbins 和 Greg Stein（當時是一個獨立開發者，活躍在WebDAV/DeltaV 系統規範階段）的恰當激勵的幫助下，SVN 很快吸引了許多活躍的開發者，結果是許多有CVS 經驗的人們很樂於有機會爲這個項目做些事情。
最初的設計小組固定在簡單的目標上，他們不想在版本控制方法學中開墾處女地，他們只是希望修正CVS，他們決定SVN 匹配CVS 的特性，保留相同的開發模型，但不復制CVS 明顯的缺陷。儘管它不需要成爲CVS的繼任者，它也應該與CVS 保持足夠的相似性，使得CVS 用戶可以輕鬆的做出轉換。
經過14 個月的編碼，2001 年8 月31 日，SVN 自己能夠“成爲服務”了，開發者停止使用CVS 保存SVN 的代碼，而使用SVN 本身。
當CollabNet 開始這個項目的時候，曾經資助了大量的工作（它爲全職的SVN 開發者提供薪水），SVN 像許多開源項目一樣，被一些激勵知識界精英的寬鬆透明的規則支配着。CollabNet的版權許可證完全符合Debian的自由軟件方針，也就是說，任何人可以自由的下載，修改和重新發布，不需要經過CollabNet 或其他人的允許。
SVN和CVS功能性對比：
一、SVN包含絕大部分CVS功能
SVN 作爲CVS 的重寫版和改進版，其目標就是作爲一個更好的版本控制軟件，取代目前流行的CVS。SVN 的主要開發人員都是業界知名的CVS 專家。SVN支持絕大部分的CVS 功能/命令；SVN 的命令風格和界面也與CVS 非常接近。當然，不同的地方正是對CVS 的改進。
二、全局性的版本編號
一個新的版本，並得到一個自增量的版本號N+1，該版本號並不針對某個特定的文件，而是全局性的、針對整個版本庫的。因此，我們可以將SVN 的版本庫看作是一個文件系統或文件目錄樹的數組。
從技術的角度來說，在SVN 中，“文件foo.c 的第5 版本”這個說法是錯誤的；正確的說法應該是：”文件foo.c 在版本庫被修改了5 次，即執行5 次commit 後是什麼樣子？”。顯然，在SVN 中，版本庫被修改5 次後foo.c 的內容，和被修改了6 次後foo.c 的內容很可能完全一樣，因爲版本庫的第6 次修改很可能只修改了版本庫的其他部分，而並沒有對foo.c 的進行修改。相反，在CVS 中，文件foo.c 的第1.1 版本和第1.2 版本總是不同的。
SVN 的全局性版本編號爲SVN 帶來了諸多的優勢：如對目錄或文件執行拷貝，無論涉及多少文件，SVN 不需要對單個文件依次執行拷貝命令，僅僅需要建立一個指向相應的全局版本號的一個指針即可。
三、目錄的版本控制
CVS 只能對文件進行版本控制，不能對目錄進行版本控制，因此CVS 沒有任何關於文件“移動”（move）
操作的概念。當人爲進行文件移動操作時，CVS 只能注意到，一個文件在一個位置被刪除了，而在一個新位置創建了另外一個文件。由於它不會連接兩個操作，因此也很容易使文件歷史軌跡丟失。設置 CVS 存儲庫時，必須非常謹慎地爲每個文件選擇準確的位置，因爲在設置之後，幾乎就要一直使用這個位置了。
同樣由於CVS 不記錄目錄的版本歷史，CVS 不支持對文件的“重命名”（rename），人爲的對文件進行重命名會使得命名前後的文件失去歷史聯繫，而記錄歷史本來是版本管理的主要目的。
還有，CVS 不支持對文件的“拷貝”（copy），人爲的拷貝對CVS 而言，只能看到新的文件的增加，而不能記錄拷貝源文件和目標文件之間的聯繫。
綜上所述，缺乏對文件“移動”、“重命名”、“拷貝”的支持的根源在於CVS 不能記錄目錄的版本歷史，而這些操作在當前的軟件開發過程中經常發生，這正是SVN被開發並取代CVS 的主要原因之一。
SVN 將目錄作爲一類特殊的文件來處理（事實上，從文件系統的角度來看，目錄確實是一類特殊的文件，當目錄中的子目錄/文件被刪除、重命名、或新的子目錄/文件被創建時，目錄的內容將發生改變）。因此，SVN 象記錄普通文件的修改歷史一樣記錄對目錄的修改歷史，當發生文件/目錄的移動、重命名或拷貝操作時，SVN 能夠準確記錄操作前後的歷史聯繫。同樣，象對文件的不同歷史版本進行比較一樣，SVN支持對目錄的不同歷史版本的比較，清晰展現目錄的變化歷史。
四、原子性提交
從使用者的角度來看，CVS 和SVN 都支持對多個文件修改的批量提交，但二者在實現方式上存在本質的區別。 CVS 採用線性、串行的批量提交，即依次地，一個接一個地執行提交，每成功提交一個文件，該文件的一個新的版本即被記錄到版本庫中，提交時用戶提供的日誌信息被重複地存儲到每一個被修改的文件的版本歷史中。
CVS 串行批量提交模式的弊端在於
－
當任何原因造成批量操作的中斷時（典型原因包括：網絡中斷、客戶端死機等），版本庫往往處於一個不一致的狀態：原本應該全部入庫的文件只有一部分入庫，很有可能版本庫中的最新版本不能順利編譯，更爲嚴重的是，隨着其他的用戶執行cvs update 操作，該不一致性將迅速在開發團隊中擴散，從而嚴重影響團隊的開發效率，並存在質量隱患。另外，假如該批量提交的中斷沒有被及時發現，開發團隊往往要花更多的時間進行軟件調試和排錯。
CVS 即使在批量提交不發生中斷時也會造成不一致：假設用戶A 啓動一個需要較長時間才能完成的批量提交；與此同時，用戶B 執行cvs update 操作。此時，用戶B 很有可能得到一個不一致的更新，即用戶B 通過“更新”操作，得到用戶A 的部分修改文件。
SVN 徹底消除了CVS 的以上弊端。無論批量提交包含多少文件修改，只有當全部文件修改都成功入庫，該提交才變得有效，纔對其他用戶可見；否則，無論任何原因造成中斷，SVN 都會自動執行“回滾”（rollback）操作。換一個說法，SVN 保證所有的修改要麼全部入庫生效，要麼一個也不入庫，即對版本庫不作任何的修改。這就是SVN 的原子性提交（atomic commit）。
由於SVN 的原子性提交特性和全局版本編號方式，當提交成功完成時，一個唯一的、新的全局版本編號產生，而提交時用戶提供的日誌信息與該新的版本編號關聯，只進行一次存儲（區別於CVS 的按文件重複存儲）。
五、支持變更集概念
由於SVN 的所有提交是原子性的，每次成功提交形成的唯一的全局版本號對應此次批量提交的所有文件修改，也就是說，一個SVN 版本號其實對應了一個邏輯上的變更集（change set），該變更集可能對應於對一個BUG 的修復，或者對應於對一個已有功能的改進，或者對應於一個新功能的實現。可以說，變更集是一個軟件開發活動的邏輯結果，該變更集可以通過其對應的版本號在軟件開發的其他過程中（如軟件合併/集成過程，軟件發佈管理，變更管理系統，缺陷追蹤系統）被引用。因此，SVN 將版本管理從單純的、單個的文件修改的層次通過邏輯上的抽象，上升到更便於理解和交流的開發活動的層次。
六、差異化的二進制文件處理
由於歷史原因，CVS 主要是爲早期的程序員設計的，CVS 能夠有效處理文本文件（或ASCII文件，源代碼文件），可以對文本文件進行差異化的存儲、新舊版本的比較，文件合併等；但對於二進制文件，CVS 則明顯力不從心。在CVS 的版本庫中，對於二進制文件的歷史版本，CVS 唯一能做的就是對不同的版本進行獨立的、冗餘的存儲，哪怕版本之間其實只存在微小的差異。舉例而言，一個10M
的二進制文件（照片、圖形文件、機械設計文件、電子設計文件）假如每週修改一次，無論每次修改的大小，一年下來，僅該文件就要消耗500M
以上的存儲空間。而且，客戶端每次獲取該文件的新版本都要消耗10M
的網絡流量。
對於目前的開發團隊，無論是軟件開發，Web 站點的開發，手機等電子產品的研發，需要進行版本管理的不僅是源代碼等文本文件，還需要管理需求文檔、設計文檔、測試文檔、用戶手冊，圖形圖像文件，機械/電子設計文件等諸多的二進制文件，CVS 顯然不是一個好的選擇。
與CVS 不同，SVN 採用統一的二進制差異算法（binary differencing algorithm），即對文本文件和二進制文件採用相同的差異比較算法，並以相同的方式在版本庫中進行存儲：每次提交後版本庫中只存儲相對於先前版本的差異，從而可以節省大量的存儲空間。
該二進制差異算法不僅應用在版本的存儲上，更爲重要的是，SVN 對二進制文件與文本文件一視同仁，當客戶端需要獲取新的版本時（如執行svn update），在網絡上只有版本的差異被傳輸，從而大大減少對網絡帶寬的消耗。更多細節參見“七、雙向的差異化－壓縮網絡傳輸”。
七、
雙向的差異化－壓縮網絡傳輸
如上所述，CVS 對二進制文件不能進行有效的差異化處理。對於文本文件，CVS 僅僅支持單向的差異化傳輸：從CVS 服務器到客戶端的傳輸是差異化的，即執行cvs update 時，只有差異的部分從服務器傳輸到客戶端；而當執行cvs commit 時，無論代碼變化多少，CVS 都需要從客戶端向服務器完整傳輸被修改文件的全部內容，不能只傳輸差異。
相反，無論是文本文件還是二進制文件，SVN 都進行雙向的差異化傳輸，並且差異化內容還要進行壓縮/解壓縮的過程：在服務器端獲取差異顯而易見，與CVS 類似；SVN 在客戶端獲取差異的祕密在於 — SVN 在客戶端的工作拷貝中隱含了每個文件的一個“只讀的、乾淨的”副本（該副本隱藏在隱含目錄.svn 裏，通常不可見，該副本還有更多的妙用，參見“十二、更多的本地/離線操作”），通過比較用戶在客戶端的修改和該隱含的副本，SVN 獲取需要真正傳送到服務器的差異，並對差異進行壓縮後才進行網絡傳輸。
對CVS 而言，操作的成本（網絡帶寬消耗是最大的操作成本）與被修改的文件的大小成比例，而與修改本身的大小無關；對SVN 而言，操作成本只與修改本身的大小成比例，而與被修改的文件的大小無關。因此，與CVS 相比，SVN 消耗更少的網絡帶寬（以客戶端的存儲空間換取更少的帶寬消耗在目前的計算環境下應該是個相當不錯的選擇！）。SVN 更加適合基於互聯網（或廣域網）進行協作開發的地理上分佈的團隊 — 版本服務器集中、單一；客戶端廣泛分佈。
CVS 只能對文件進行版本控制，不能對目錄進行版本控制，因此CVS 沒有任何關於文件“移動”（move）
操作的概念。當人爲進行文件移動操作時，CVS 只能注意到，一個文件在一個位置被刪除了，而在一個新位置創建了另外一個文件。由於它不會連接兩個操作，因此也很容易使文件歷史軌跡丟失。設置 CVS 存儲庫時，必須非常謹慎地爲每個文件選擇準確的位置，因爲在設置之後，幾乎就要一直使用這個位置了。
同樣由於CVS 不記錄目錄的版本歷史，CVS 不支持對文件的“重命名”（rename），人爲的對文件進行重命名會使得命名前後的文件失去歷史聯繫，而記錄歷史本來是版本管理的主要目的。
還有，CVS 不支持對文件的“拷貝”（copy），人爲的拷貝對CVS 而言，只能看到新的文件的增加，而不能記錄拷貝源文件和目標文件之間的聯繫。
綜上所述，缺乏對文件“移動”、“重命名”、“拷貝”的支持的根源在於CVS 不能記錄目錄的版本歷史，而這些操作在當前的軟件開發過程中經常發生，這正是SVN被開發並取代CVS 的主要原因之一。
SVN 將目錄作爲一類特殊的文件來處理（事實上，從文件系統的角度來看，目錄確實是一類特殊的文件，當目錄中的子目錄/文件被刪除、重命名、或新的子目錄/文件被創建時，目錄的內容將發生改變）。因此，SVN 象記錄普通文件的修改歷史一樣記錄對目錄的修改歷史，當發生文件/目錄的移動、重命名或拷貝操作時，SVN 能夠準確記錄操作前後的歷史聯繫。同樣，象對文件的不同歷史版本進行比較一樣，SVN支持對目錄的不同歷史版本的比較，清晰展現目錄的變化歷史。
四、原子性提交
從使用者的角度來看，CVS 和SVN 都支持對多個文件修改的批量提交，但二者在實現方式上存在本質的區別。 CVS 採用線性、串行的批量提交，即依次地，一個接一個地執行提交，每成功提交一個文件，該文件的一個新的版本即被記錄到版本庫中，提交時用戶提供的日誌信息被重複地存儲到每一個被修改的文件的版本歷史中。
CVS 串行批量提交模式的弊端在於
－
當任何原因造成批量操作的中斷時（典型原因包括：網絡中斷、客戶端死機等），版本庫往往處於一個不一致的狀態：原本應該全部入庫的文件只有一部分入庫，很有可能版本庫中的最新版本不能順利編譯，更爲嚴重的是，隨着其他的用戶執行cvs update 操作，該不一致性將迅速在開發團隊中擴散，從而嚴重影響團隊的開發效率，並存在質量隱患。另外，假如該批量提交的中斷沒有被及時發現，開發團隊往往要花更多的時間進行軟件調試和排錯。
CVS 即使在批量提交不發生中斷時也會造成不一致：假設用戶A 啓動一個需要較長時間才能完成的批量提交；與此同時，用戶B 執行cvs update 操作。此時，用戶B 很有可能得到一個不一致的更新，即用戶B 通過“更新”操作，得到用戶A 的部分修改文件。
SVN 徹底消除了CVS 的以上弊端。無論批量提交包含多少文件修改，只有當全部文件修改都成功入庫，該提交才變得有效，纔對其他用戶可見；否則，無論任何原因造成中斷，SVN 都會自動執行“回滾”（rollback）操作。換一個說法，SVN 保證所有的修改要麼全部入庫生效，要麼一個也不入庫，即對版本庫不作任何的修改。這就是SVN 的原子性提交（atomic commit）。
由於SVN 的原子性提交特性和全局版本編號方式，當提交成功完成時，一個唯一的、新的全局版本編號產生，而提交時用戶提供的日誌信息與該新的版本編號關聯，只進行一次存儲（區別於CVS 的按文件重複存儲）。
五、支持變更集概念
由於SVN 的所有提交是原子性的，每次成功提交形成的唯一的全局版本號對應此次批量提交的所有文件修改，也就是說，一個SVN 版本號其實對應了一個邏輯上的變更集（change set），該變更集可能對應於對一個BUG 的修復，或者對應於對一個已有功能的改進，或者對應於一個新功能的實現。可以說，變更集是一個軟件開發活動的邏輯結果，該變更集可以通過其對應的版本號在軟件開發的其他過程中（如軟件合併/集成過程，軟件發佈管理，變更管理系統，缺陷追蹤系統）被引用。因此，SVN 將版本管理從單純的、單個的文件修改的層次通過邏輯上的抽象，上升到更便於理解和交流的開發活動的層次。
六、差異化的二進制文件處理
由於歷史原因，CVS 主要是爲早期的程序員設計的，CVS 能夠有效處理文本文件（或ASCII文件，源代碼文件），可以對文本文件進行差異化的存儲、新舊版本的比較，文件合併等；但對於二進制文件，CVS 則明顯力不從心。在CVS 的版本庫中，對於二進制文件的歷史版本，CVS 唯一能做的就是對不同的版本進行獨立的、冗餘的存儲，哪怕版本之間其實只存在微小的差異。舉例而言，一個10M
的二進制文件（照片、圖形文件、機械設計文件、電子設計文件）假如每週修改一次，無論每次修改的大小，一年下來，僅該文件就要消耗500M
以上的存儲空間。而且，客戶端每次獲取該文件的新版本都要消耗10M
的網絡流量。
對於目前的開發團隊，無論是軟件開發，Web 站點的開發，手機等電子產品的研發，需要進行版本管理的不僅是源代碼等文本文件，還需要管理需求文檔、設計文檔、測試文檔、用戶手冊，圖形圖像文件，機械/電子設計文件等諸多的二進制文件，CVS 顯然不是一個好的選擇。
與CVS 不同，SVN 採用統一的二進制差異算法（binary differencing algorithm），即對文本文件和二進制文件採用相同的差異比較算法，並以相同的方式在版本庫中進行存儲：每次提交後版本庫中只存儲相對於先前版本的差異，從而可以節省大量的存儲空間。
該二進制差異算法不僅應用在版本的存儲上，更爲重要的是，SVN 對二進制文件與文本文件一視同仁，當客戶端需要獲取新的版本時（如執行svn update），在網絡上只有版本的差異被傳輸，從而大大減少對網絡帶寬的消耗。更多細節參見“七、雙向的差異化－壓縮網絡傳輸”。
七、
雙向的差異化－壓縮網絡傳輸
如上所述，CVS 對二進制文件不能進行有效的差異化處理。對於文本文件，CVS 僅僅支持單向的差異化傳輸：從CVS 服務器到客戶端的傳輸是差異化的，即執行cvs update 時，只有差異的部分從服務器傳輸到客戶端；而當執行cvs commit 時，無論代碼變化多少，CVS 都需要從客戶端向服務器完整傳輸被修改文件的全部內容，不能只傳輸差異。
相反，無論是文本文件還是二進制文件，SVN 都進行雙向的差異化傳輸，並且差異化內容還要進行壓縮/解壓縮的過程：在服務器端獲取差異顯而易見，與CVS 類似；SVN 在客戶端獲取差異的祕密在於 — SVN 在客戶端的工作拷貝中隱含了每個文件的一個“只讀的、乾淨的”副本（該副本隱藏在隱含目錄.svn 裏，通常不可見，該副本還有更多的妙用，參見“十二、更多的本地/離線操作”），通過比較用戶在客戶端的修改和該隱含的副本，SVN 獲取需要真正傳送到服務器的差異，並對差異進行壓縮後才進行網絡傳輸。
對CVS 而言，操作的成本（網絡帶寬消耗是最大的操作成本）與被修改的文件的大小成比例，而與修改本身的大小無關；對SVN 而言，操作成本只與修改本身的大小成比例，而與被修改的文件的大小無關。因此，與CVS 相比，SVN 消耗更少的網絡帶寬（以客戶端的存儲空間換取更少的帶寬消耗在目前的計算環境下應該是個相當不錯的選擇！）。SVN 更加適合基於互聯網（或廣域網）進行協作開發的地理上分佈的團隊 — 版本服務器集中、單一；客戶端廣泛分佈。
八、高效、快捷創建分支和基線
CVS 和SVN 都支持分支（branch）和基線（tag），通過分支與合併，可以有效支持大項目的並行開發模式；通過基線管理，可以準確標識一組文件的版本，有效進行軟件發佈管理和必要時的歷史回溯。
但CVS 和SVN 在實現分支和基線的方式上存在很大的不同。CVS 在創建分支的時候，需要對所有進行分支的文件進行依次的操作，因此分支的建立成本（主要是建立分支所需的時間，或消耗的計算資源）與參與分支的文件數量成比例，項目越大，版本庫越大，文件越多，分支的建立成本越高；基線（tag）的建立與此類似。
SVN 的分支和基線是通過執行“拷貝”來建立的：回想一下在沒有引入版本管理工具的時候我們是如何進行所謂的“分支”和“基線”管理的？答案顯然是“拷貝” — 我們通過“拷貝”或“備份”來建立基線；同樣，爲支持多個開發人員可以同時進行開發，我們爲每個開發人員創建一份“拷貝”。由此看來，SVN 通過“拷貝”來建立分支和基線顯得非常自然，有點“返樸歸真”的意思。
由於SVN 的全局版本號特性，SVN 中分支或基線的創建過程，或SVN中的“拷貝”過程，真正的操作是在版本庫中創建一個到某一全局版本號的指針（pointer），不再需要針對衆多的單個文件依次執行操作。因此，該操作的成本爲一個很小的常數，與項目大小，版本庫大小，文件數目的多少無關；並且，分支或基線的建立不需要進行版本的冗餘存儲，新建立的分支或基線基本不佔用版本庫空間，分支的後續存儲空間的開銷也只與修改的大小有關。
九、集成Apache Web Server，提供更多的特性
SVN 通過與Apache Web Server 的集成，可以提供基於http/https 協議的版本庫訪問機制，從而支持SVN 跨越防火牆的安全訪問。除此以外，SVN 還可以利用更多的Apache 特性，包括但不限於：Apache 豐富的用戶認證機制（包括通過LDAP服務器如Windows Active Directory 服務器的用戶認證），基於目錄路徑的精細粒度的訪問控制，對傳輸的網絡流量進行壓縮/解壓縮，瀏覽版本庫目錄結構等等。
十、支持WebDAV
WebDAV（Web-based Distributed Authoring and Versioning）是一種基於 HTTP 1.1 協議的通信協議.它擴展了HTTP 1.1，在GET、POST、HEAD 等幾個HTTP 標準方法以外添加了一些新的方法，使應用程序可直接對Web Server 直接讀寫，並支持寫文件鎖定(Locking)及解鎖(Unlock)，還可以支持文件的版本控制。
Microsoft windows2000/XP 及IE, Office 還有Adobe/MicroMedia 的DW 等都支持WebDAV，這又大大增強了Web 應用的價值，以及效能。對於需要大量發佈內容的用戶而言，應用WebDAV 可以降低對CMS 系統的依賴，而且能夠更自由的進行創作。上傳、下載變得輕鬆自如。
SVN 通過與Apache Web Server 的集成，支持WebDAV 協議，使得業務用戶（business users）或非技術用戶在不安裝任何版本管理客戶端的情況下輕鬆訪問SVN 版本庫，不改變業務用戶已有使用習慣，支持分佈的業務用戶對文檔的評審、修改並實現版本控制，真正將軟件開發的生命週期從開發/技術團隊擴展到項目的全部干係人（stakeholder），避免通過電子郵件傳遞文檔的混亂與無序、通過Windows 操作系統共享造成的安全漏洞、病毒攻擊、歷史版本被覆蓋或丟失、審計困難等諸多典型問題。
十一、更好的衝突標識與處理
CVS 和SVN 都支持通過分支與合併進行並行開發，並可以自動檢測到合併時的衝突（conflicts），並在合併結果中以<<<<<< … >>>>>>標識合併的衝突部分。
在CVS 中，經常會出現由於用戶的疏忽（如，沒有注意到衝突，或沒有完全處理好衝突）而將仍然帶有<<<<<< … >>>>>>衝突標識符號的文件直接進行提交（commit），從而在版本庫中產生垃圾版本。
SVN 有效解決了CVS 的以上問題：SVN 記錄並保持文件的衝突狀態，只有當用戶明確執行svn resolved 命令後，該衝突狀態標識才被複位，該文件才能被提交，從而大大減少了將仍然帶有<<<<<< … >>>>>>衝突標識符號的文件直接進行提交的可能性。
十二、
更多的本地/離線操作
衆所周知，CVS 客戶端的工作拷貝中包含了一個隱含目錄CVS，該目錄中記錄了客戶端需要的一些管理信息；與此類似，SVN 的客戶端工作拷貝中也包含了一個隱含目錄.svn，該目錄中同樣記錄了客戶端需要的一些管理信息，如版本庫URL，當前訪問版本號等。
與CVS 不同的是，SVN 的.svn 目錄中還包含了工作拷貝中每一個文件的一個“只讀的、乾淨的”副本。正是由於該副本的存在，使得SVN 與CVS 相比，可以執行更多的本地/離線操作，即某些操作不需要訪問版本庫服務器，因此不需要存在從客戶端到服務器的網絡鏈接，當然也不消耗任何網絡帶寬，這進一步增強了SVN 對廣域網的友好支持。
SVN 的以下命令可以進行離線操作：
svn status －
顯示工作拷貝上的本地修改概況；
svn diff －顯示工作拷貝上的本地修改細節，比較修改前後的內容；
svn revert －
撤銷工作拷貝上的本地修改；
十三、
對符號鏈接進行版本管理
在Unix 文件系統中，符號鏈接（symbolic links，包括硬鏈接和軟鏈接）是一種重要的文件系統元素。CVS 不能對符號鏈接進行版本管理；SVN 則可以對符號鏈接進行版本管理。
十四、
元數據管理
與CVS 相比，SVN 增加了元數據（metadata）管理機制。即可以對版本庫中的文件或目錄附加任意的“屬性”（property），並記錄屬性的變化歷史，也就是對元數據進行版本管理。一個SVN 屬性是一個“屬性名稱/屬性值”的二元組，如“BugNumber= 100”就是一個屬性，可以將該屬性附加到版本N 上，以說明版本N 改正了編號爲100的BUG。
SVN 元數據的目的是提供附件的信息以滿足流程或過程自動化的需要，以增強SVN 的管理能力和自動化程度。SVN 自身就通過“屬性”來存儲一些特殊的信息。一個使用SVN 元數據的例子：可以在一些批處理的腳本程序或SVN的鉤子程序（hooks）中創建、訪問、修改“屬性”元數據來滿足流程自動化的要求。
非功能性對比：性能、可用性、可擴展性：
一、層次化的體系架構
儘管CVS 是開放源代碼的，但同樣由於歷史的原因，即使是CVS 的主要開發和維護人員也認爲目前CVS 的代碼很難進行後續的維護和擴展，而這正是SVN 被重寫的主要原因之一。
CVS 和SVN 都支持分支（branch）和基線（tag），通過分支與合併，可以有效支持大項目的並行開發模式；通過基線管理，可以準確標識一組文件的版本，有效進行軟件發佈管理和必要時的歷史回溯。
但CVS 和SVN 在實現分支和基線的方式上存在很大的不同。CVS 在創建分支的時候，需要對所有進行分支的文件進行依次的操作，因此分支的建立成本（主要是建立分支所需的時間，或消耗的計算資源）與參與分支的文件數量成比例，項目越大，版本庫越大，文件越多，分支的建立成本越高；基線（tag）的建立與此類似。
SVN 的分支和基線是通過執行“拷貝”來建立的：回想一下在沒有引入版本管理工具的時候我們是如何進行所謂的“分支”和“基線”管理的？答案顯然是“拷貝” — 我們通過“拷貝”或“備份”來建立基線；同樣，爲支持多個開發人員可以同時進行開發，我們爲每個開發人員創建一份“拷貝”。由此看來，SVN 通過“拷貝”來建立分支和基線顯得非常自然，有點“返樸歸真”的意思。
由於SVN 的全局版本號特性，SVN 中分支或基線的創建過程，或SVN中的“拷貝”過程，真正的操作是在版本庫中創建一個到某一全局版本號的指針（pointer），不再需要針對衆多的單個文件依次執行操作。因此，該操作的成本爲一個很小的常數，與項目大小，版本庫大小，文件數目的多少無關；並且，分支或基線的建立不需要進行版本的冗餘存儲，新建立的分支或基線基本不佔用版本庫空間，分支的後續存儲空間的開銷也只與修改的大小有關。
九、集成Apache Web Server，提供更多的特性
SVN 通過與Apache Web Server 的集成，可以提供基於http/https 協議的版本庫訪問機制，從而支持SVN 跨越防火牆的安全訪問。除此以外，SVN 還可以利用更多的Apache 特性，包括但不限於：Apache 豐富的用戶認證機制（包括通過LDAP服務器如Windows Active Directory 服務器的用戶認證），基於目錄路徑的精細粒度的訪問控制，對傳輸的網絡流量進行壓縮/解壓縮，瀏覽版本庫目錄結構等等。
十、支持WebDAV
WebDAV（Web-based Distributed Authoring and Versioning）是一種基於 HTTP 1.1 協議的通信協議.它擴展了HTTP 1.1，在GET、POST、HEAD 等幾個HTTP 標準方法以外添加了一些新的方法，使應用程序可直接對Web Server 直接讀寫，並支持寫文件鎖定(Locking)及解鎖(Unlock)，還可以支持文件的版本控制。
Microsoft windows2000/XP 及IE, Office 還有Adobe/MicroMedia 的DW 等都支持WebDAV，這又大大增強了Web 應用的價值，以及效能。對於需要大量發佈內容的用戶而言，應用WebDAV 可以降低對CMS 系統的依賴，而且能夠更自由的進行創作。上傳、下載變得輕鬆自如。
SVN 通過與Apache Web Server 的集成，支持WebDAV 協議，使得業務用戶（business users）或非技術用戶在不安裝任何版本管理客戶端的情況下輕鬆訪問SVN 版本庫，不改變業務用戶已有使用習慣，支持分佈的業務用戶對文檔的評審、修改並實現版本控制，真正將軟件開發的生命週期從開發/技術團隊擴展到項目的全部干係人（stakeholder），避免通過電子郵件傳遞文檔的混亂與無序、通過Windows 操作系統共享造成的安全漏洞、病毒攻擊、歷史版本被覆蓋或丟失、審計困難等諸多典型問題。
十一、更好的衝突標識與處理
CVS 和SVN 都支持通過分支與合併進行並行開發，並可以自動檢測到合併時的衝突（conflicts），並在合併結果中以<<<<<< … >>>>>>標識合併的衝突部分。
在CVS 中，經常會出現由於用戶的疏忽（如，沒有注意到衝突，或沒有完全處理好衝突）而將仍然帶有<<<<<< … >>>>>>衝突標識符號的文件直接進行提交（commit），從而在版本庫中產生垃圾版本。
SVN 有效解決了CVS 的以上問題：SVN 記錄並保持文件的衝突狀態，只有當用戶明確執行svn resolved 命令後，該衝突狀態標識才被複位，該文件才能被提交，從而大大減少了將仍然帶有<<<<<< … >>>>>>衝突標識符號的文件直接進行提交的可能性。
十二、
更多的本地/離線操作
衆所周知，CVS 客戶端的工作拷貝中包含了一個隱含目錄CVS，該目錄中記錄了客戶端需要的一些管理信息；與此類似，SVN 的客戶端工作拷貝中也包含了一個隱含目錄.svn，該目錄中同樣記錄了客戶端需要的一些管理信息，如版本庫URL，當前訪問版本號等。
與CVS 不同的是，SVN 的.svn 目錄中還包含了工作拷貝中每一個文件的一個“只讀的、乾淨的”副本。正是由於該副本的存在，使得SVN 與CVS 相比，可以執行更多的本地/離線操作，即某些操作不需要訪問版本庫服務器，因此不需要存在從客戶端到服務器的網絡鏈接，當然也不消耗任何網絡帶寬，這進一步增強了SVN 對廣域網的友好支持。
SVN 的以下命令可以進行離線操作：
svn status －
顯示工作拷貝上的本地修改概況；
svn diff －顯示工作拷貝上的本地修改細節，比較修改前後的內容；
svn revert －
撤銷工作拷貝上的本地修改；
十三、
對符號鏈接進行版本管理
在Unix 文件系統中，符號鏈接（symbolic links，包括硬鏈接和軟鏈接）是一種重要的文件系統元素。CVS 不能對符號鏈接進行版本管理；SVN 則可以對符號鏈接進行版本管理。
十四、
元數據管理
與CVS 相比，SVN 增加了元數據（metadata）管理機制。即可以對版本庫中的文件或目錄附加任意的“屬性”（property），並記錄屬性的變化歷史，也就是對元數據進行版本管理。一個SVN 屬性是一個“屬性名稱/屬性值”的二元組，如“BugNumber= 100”就是一個屬性，可以將該屬性附加到版本N 上，以說明版本N 改正了編號爲100的BUG。
SVN 元數據的目的是提供附件的信息以滿足流程或過程自動化的需要，以增強SVN 的管理能力和自動化程度。SVN 自身就通過“屬性”來存儲一些特殊的信息。一個使用SVN 元數據的例子：可以在一些批處理的腳本程序或SVN的鉤子程序（hooks）中創建、訪問、修改“屬性”元數據來滿足流程自動化的要求。
非功能性對比：性能、可用性、可擴展性：
一、層次化的體系架構
儘管CVS 是開放源代碼的，但同樣由於歷史的原因，即使是CVS 的主要開發和維護人員也認爲目前CVS 的代碼很難進行後續的維護和擴展，而這正是SVN 被重寫的主要原因之一。
SVN 具備設計良好的三層體系架構
－
版本庫層（Repository Layer），版本庫訪問層（Repository Access Layer），和客戶端層（Client Layer）。 SVN 在層與層之間定義了明確的接口，使之具備更好的擴展性。
SVN 的體系架構如下圖所示：
二、可選的後臺版本庫實現
CVS 的版本庫以普通的文件系統方式實現；SVN 的版本庫支持兩種實現方式：以嵌入式的數據庫BerkeleyDB 實現，或，採用特定格式的普通文件系統FSFS 方式實現。二者在可擴展性、性能、備份/恢復等方面各有特色，用戶可以根據自身的實際需求進行靈活的選擇。
三、更好的性能和可用性
由於CVS 主要針對文本文件的版本處理而設計，CVS 在處理大文件時存在性能和可用性問題
－ CVS 在執行提交時需要向服務器傳輸整個文件的內容。一方面，處理文件的大小受制與客戶端可用內存的多少；另一方面，大文件的處理將佔用服務器的絕大部分資源，可能導致服務器性能嚴重下降，使得其他用戶無法訪問和工作，甚至出現服務器宕機。
SVN 從設計上根本杜絕了CVS 的上述問題。SVN 能夠處理任意大小的文件，包括比可用內存還大的文件，並且無論是在客戶端還是在服務器端，SVN 始終只需要一個相對小、相對固定的內存開銷
－ SVN 能夠進行雙向的差異化/壓縮的網絡傳輸，而且無論差異的大小，SVN 始終以大小固定的管道方式或流模式（stream）執行網絡傳輸。事實上，由於客戶端參與了差異的計算，SVN 讓大量的客戶端一起分擔服務器的處理負荷，從而從整體上提高了SVN 的性能和可用性。
四、可解析、格式規範的輸出
從用戶的角度來看，命令行方式下的SVN 的風格與CVS 的風格非常類似，但SVN 還是做了重大的改進：SVN 命令行方式下的輸出經過了“認真、仔細”的設計，使得其輸出不僅便於“人”的閱讀和理解，同樣便於程序腳本的自動化解析，或者說，適合“機器”的閱讀和理解。因此，在SVN 下編寫批量的自動化腳本程序更加容易，腳本工作更加可靠。
五、更好的本地化、國際化支持
SVN 從一開始就充分考慮到本地化（ Localization ， L10N ）
、國際化（Internationalization， I18N）方面的需求，無論是對多字節文件，多字節文件名的版本管理，還是客戶端工具的用戶界面/輸出提示信息本地化等，SVN 都比CVS 做得更好。
六、豐富的可選組件
·SVN 有大量的客戶端工具和服務器工具可供選擇，主流的SVN 客戶端有：
·SVN 命令行客戶端
－
支持各種操作系統平臺
·TortoiseSVN – Windows 下與資源管理器緊密集成的圖形界面客戶端
·Subclipse – SVN 的Eclipse 插件
七、支持從CVS到SVN的版本庫遷移
由於SVN 與CVS 的諸多共性和歷史淵源，現有的CVS 版本庫可以很方便地轉換成（或遷移到）SVN 版本庫格式，使得在保留原來的CVS 歷史版本信息的同時在SVN 下繼續使用。現成的轉換工具有：cvs2svn，該轉換工具由SVN 的核心開發團隊開發和維護。
3.4
ClearCase優點：功能強大，版本管理和分支管理完全自動化。
缺點：權限管理只能是基於Windows的用戶安全權限管理。
隨着軟件團隊人員的增加，軟件版本不斷變化，時間的緊缺，多種平臺的複雜環境，使得 ClearCase所擁有的特殊組件已成爲當今軟件開發人員（工程人員和管理者）所必須的工具。分佈式操作使得基於Client/Server的運算結構跨越於網上客戶機和服務器，ClearCase的先進功能直接解決了原來開發團隊所面臨的難以處理的問題。
軟件開發所面臨的問題包括：對當前多種產品的開發和維護，保證產品版本的精確，重建先前發佈的產品，加強開發政策的統一和對特殊版本需求的處理。通過解決這些問題，ClearCase用資源重用的方法幫助開發團隊使他們所有的軟件建立得更加可靠。 Rational公司的ClearCase是軟件配置領域的先導，它主要基於Windows和UNIX的開發環境。它提供了全面的配置管理──包括版本控制、工作空間管理、建立管理和過程控制，而且無須軟件開發者改變他們現有的環境、工具和工作方式。
ClearCase的核心功能是版本控制，它是對在軟件開發進程中一個文件或一個目錄發展過程進行追蹤的手段。ClearCase對所有文件系統對象（包括文件、目錄和鏈接）增強了版本控制系統功能。可定版本的文件包括源代碼、可執行文件、位圖文件、需求文檔、設計說明、測試計劃、和一些ASCII和非ASCII文件。目錄的版本記錄了整個組織基礎資源的發展狀況，包括源文件的建立、重新命名、重新構造和刪除操作等。 這種版本控制系統提供了先進的版本分支和歸併功能用於支持並行開發。
3.4.1
控制任何文件的版本
ClearCase可以對每一個軟件組件或元件的版本進行維護和控制。ClearCase也可以維護一個非文本文件、目錄和工具的版本。正如：它可以管理庫文件、編譯器、需求文檔、
測試包和數據庫而不僅僅是源代碼。
ClearCase的元件類型可以管理版本內容。用戶可以定義自己的元件類型，也可以使用ClearCase中的預定義類型：文本文件、壓縮文本文件、文件、壓縮文件和二進制增量文件。
ClearCase可以利用增量算法將文本文件存儲在一個特殊結構的文件容器中。ClearCase採用標準的壓縮技術和增量算法存儲一個壓縮文本文件。（這比以往的存儲形式節省了50%―70%的存儲空間。）
這種元件類型文件和壓縮文件可以被用於控制任何操作系統文件──比如，可執行程序、程序資源庫、結構數據庫和結構文檔文件。二進制增量文件類型可以隨時被用於二進制文件格式。
3.4.2
在版本樹中組織元件發展的過程 在ClearCase中，元件版本的組織體現在版本樹結構中。一個版本書的結構可以按目錄結構定製，
還可以包含多層分支和子分支。
在一個典型的開發環境中，很多元件的版本樹結構最初僅包含一個分支，即，
元件的版本排列在同一條線型隊列中。隨着時間的發展，當用戶做一些錯誤修復、代碼的組織、一些實驗性修改或指定平臺的開發時，它們可以給一些相關元件定義子分支，從而脫離主幹進行開發。ClearCase可以支持多級的分支操作，還可以給版本或分支命名。
對目錄和子目錄進行版本控制
ClearCase可以對目錄和子目錄進行版本控制，允許開發者對他們數據的組織發展過程進行追蹤。目錄版本對一些改變進行控制，如：建立一個新文件、修改文件名、
建立新的子目錄或在目錄間移動文件等。
ClearCase也支持對目錄自動進行比較和歸併的操作。
存儲數據在一個可訪問的版本對象類中（VOBS）
ClearCase把所有版本控制的數據存放在一個永久、安全的存儲區中，這個存儲區被稱爲版本對象類（Version Object Bases），項目團隊（或管理者）可以決定它們所需要的VOBs的數量，可以決定什麼樣的目錄或文件需要被維護。VOBs不僅是一個可連接的文件系統而且也是網上的資源──主機可以連接任何數量的VOBs.
ClearCase VOBs的組成模式跟UNIX、Windows NT的文件系統和分佈式的數據庫系統非常類似。ClearCase採用Raima數據管理機制區維護VOB數據庫。當在ClearCase中連接和訪問時，VOB象一個標準的軟件作爲目錄樹的形式出現在客戶面前，包含標準的文件對象：目錄、文件、符號鏈接和硬鏈接。但事實上，文件系統已經有廣泛的版本控制組件：它包含目錄元素、目錄元素版本、文件元素、文件元素版本、VOB動態鏈接和VOB硬鏈接。開發者也可以查看和這些文件系統對象相關的數據。這些數據包括事件記錄，建立審覈以及用戶定義的項如：版本標籤和屬性。
3.4.3
使用常見的檢出/編輯/檢入範例
ClearCase的命令可以控制元素的變化，確保存儲區有序的繁衍並使數據損壞的程度達到最小。ClearCase採用一種檢出/編輯後檢入的範例，類似於傳統的版本控制工具如：RCS和SCCS。ClearCase除了可以進行檢出、檢入以及非檢出操作外，它還可以通過命令設置另外的操作，如：刪除版本、建立/刪除分枝、可按時間順序排列或結構排列順序列出版本歷史、比較版本間的差異，並且可以歸併並行開發的版本。
當開始對於一個指定的文件進行工作時，該文件具有隻讀屬性──這意味着它不能被編輯或刪除。而檢出操作可以對該文件的最近版本形成一個可編輯的拷貝。它無須將文件拷貝到另一區域工作。檢出的註釋可以被提供。當編輯完成後，該文件被檢入，於是在版本樹中形成一個新的版本並且將可編輯的拷貝刪除。爲了檢驗文件的變化，在檢入過程中可以填入註釋信息。文件一旦被檢入，即刻回覆到只讀狀態成爲共享數據，可被所有成員使用。
ClearCase支持兩種檢出，保留以及非保留。保留檢出可以保證版本歷史形成的正確範圍，並且同時只允許一個人做保留檢出的操作。非保留檢出無須保證建立一個成功的版本，如果多個用戶同時對同一元素執行非保留檢出，也企圖進行檢入操作，那麼第一個檢入操作被允許，而其他用戶必須通過歸併操作合併它們的結果。
豐富的註釋信息和版本數據的報表
ClearCase存儲了和文件系統對象相關又截然不同的信息類。這些信息實際上並不包含在對象中，它是一些額外數據。這些數據可以由ClearCase產生，也可以由用戶自己定義。在VOB數據庫中存儲了所有的數據。
ClearCase產生的這種數據信息提供了可靠的、面向文件系統的版本註釋信息。比如：這些數據可以驗證在某一時刻，元素A建立了一個新的版本。用戶定義的數據可以用來表達額外的功能──比如：該文件的版本曾被用於構造應用系統的4.31版。
ClearCase的操作（如：檢出、檢入、和版本歸併）可以建立時間記錄，記錄數據包含這些操作信息。這些記錄被存儲在VOB數據庫中，主要描述了該操作的屬性"誰做的、做什麼、什麼時候、在哪個地方及爲什麼"，比如：敲入命令的人員的ID號，操作的種類，操作的時間，主機名稱及用戶填入的描述。可以通過"lshistory"的命令顯示存儲在VOB中的事件記錄，並且可以通過歷史信息瀏覽器提供的圖形接口觀察VOB中的事件記錄。
用戶可以針對多種目的定義數據，包含分支的名稱、版本標籤、元素任一版本的註釋信息。
ClearCase數據的另一種應用是形成註釋的文本文件。註釋命令可以通過行顯示的形式列出任何一個版本文本文件的內容，這使得我們可以更容易的看到什麼時候在不同的地方做了添加或刪除的操作。
ClearCase也可以針對文件系統對象建立客戶報表。而報表的種類可以由用戶自己定製輸出格式。
3.4.4
通過分支功能支持並行開發
ClearCase支持並行（同時）開發，每一個元素都可以沿着不同的分枝同時發展，即新的版本加到獨立的分支上。ClearCase可以很容易的產生分支，也可以很容易的將不同分支進行合併。這樣一來，即便某一部分的工作被凍結或加鎖，開發者仍然可以繼續自己的工作（如：在軟件集成期）。在這種情況，開發者可以在分支上工作，我們知道， ClearCase的自動化操作和圖形歸併工具可以讓我們很容易的重新集成新的工作。
並行開發是非常重要的，因爲：
（1）它允許不同的項目在同一時間使用同一資源樹。
（2）它將目前不可和其他人員共享的修改成果進行隔離。
（3）它將絕對不可和其他人員共享的修改成果進行隔離（如：已發佈版本中的錯誤修復）。
（4）它使得在軟件集成期間開發工作無需停止，程序員可以先在分枝上開發，以後再集成。
爲了支持並行開發，ClearCase允許進行分支建立，追蹤分支的使用，文件比較，自動歸併功能。
3.4.5
自動的比較和版本間的歸併 並行開發的特點是對同一元素的不同版本進行定期比較，也需要對版本間內容進行歸併。在ClearCase中，對於元素或文本文件進行比較和歸併的操作有兩種：基於字符型和圖形界面型。其中，diff命令執行多文件比較，不執行歸併。而歸併命令可以處理32個"成員"，並把它們生成一個獨立的文件。 ClearCase可以自動辨認歸併選項並實現歸併。ClearCase也可以對需要歸併的項目元素進行定位。如果所有的"成員"（歸併元素）是同一元素的版本，系統會自動確定基礎"成員"，通常是最低版本。此外，ClearCase會記錄基礎版本和某一歸併元素版本間的差異。如果，所有的"成員"間差異互不相同，ClearCase會自動建立歸併版本。如果兩個或多個歸併"成員"文件內容部分不同，歸併功能會提示開發者選擇歸併內容。ClearCase也可以實現反向歸併――從主分支向子分支歸併。
ClearCase的加歸併功能可以在歸併其它分支時選擇指定的版本（那些在分支上自始至終進行變化的版本）。負歸併操作可以刪除部分版本差異，從而形成一個新的版本，該版本除了那些被刪除的變更外包含所有的改變。
－
版本庫層（Repository Layer），版本庫訪問層（Repository Access Layer），和客戶端層（Client Layer）。 SVN 在層與層之間定義了明確的接口，使之具備更好的擴展性。
SVN 的體系架構如下圖所示：
二、可選的後臺版本庫實現
CVS 的版本庫以普通的文件系統方式實現；SVN 的版本庫支持兩種實現方式：以嵌入式的數據庫BerkeleyDB 實現，或，採用特定格式的普通文件系統FSFS 方式實現。二者在可擴展性、性能、備份/恢復等方面各有特色，用戶可以根據自身的實際需求進行靈活的選擇。
三、更好的性能和可用性
由於CVS 主要針對文本文件的版本處理而設計，CVS 在處理大文件時存在性能和可用性問題
－ CVS 在執行提交時需要向服務器傳輸整個文件的內容。一方面，處理文件的大小受制與客戶端可用內存的多少；另一方面，大文件的處理將佔用服務器的絕大部分資源，可能導致服務器性能嚴重下降，使得其他用戶無法訪問和工作，甚至出現服務器宕機。
SVN 從設計上根本杜絕了CVS 的上述問題。SVN 能夠處理任意大小的文件，包括比可用內存還大的文件，並且無論是在客戶端還是在服務器端，SVN 始終只需要一個相對小、相對固定的內存開銷
－ SVN 能夠進行雙向的差異化/壓縮的網絡傳輸，而且無論差異的大小，SVN 始終以大小固定的管道方式或流模式（stream）執行網絡傳輸。事實上，由於客戶端參與了差異的計算，SVN 讓大量的客戶端一起分擔服務器的處理負荷，從而從整體上提高了SVN 的性能和可用性。
四、可解析、格式規範的輸出
從用戶的角度來看，命令行方式下的SVN 的風格與CVS 的風格非常類似，但SVN 還是做了重大的改進：SVN 命令行方式下的輸出經過了“認真、仔細”的設計，使得其輸出不僅便於“人”的閱讀和理解，同樣便於程序腳本的自動化解析，或者說，適合“機器”的閱讀和理解。因此，在SVN 下編寫批量的自動化腳本程序更加容易，腳本工作更加可靠。
五、更好的本地化、國際化支持
SVN 從一開始就充分考慮到本地化（ Localization ， L10N ）
、國際化（Internationalization， I18N）方面的需求，無論是對多字節文件，多字節文件名的版本管理，還是客戶端工具的用戶界面/輸出提示信息本地化等，SVN 都比CVS 做得更好。
六、豐富的可選組件
·SVN 有大量的客戶端工具和服務器工具可供選擇，主流的SVN 客戶端有：
·SVN 命令行客戶端
－
支持各種操作系統平臺
·TortoiseSVN – Windows 下與資源管理器緊密集成的圖形界面客戶端
·Subclipse – SVN 的Eclipse 插件
七、支持從CVS到SVN的版本庫遷移
由於SVN 與CVS 的諸多共性和歷史淵源，現有的CVS 版本庫可以很方便地轉換成（或遷移到）SVN 版本庫格式，使得在保留原來的CVS 歷史版本信息的同時在SVN 下繼續使用。現成的轉換工具有：cvs2svn，該轉換工具由SVN 的核心開發團隊開發和維護。
3.4
ClearCase優點：功能強大，版本管理和分支管理完全自動化。
缺點：權限管理只能是基於Windows的用戶安全權限管理。
隨着軟件團隊人員的增加，軟件版本不斷變化，時間的緊缺，多種平臺的複雜環境，使得 ClearCase所擁有的特殊組件已成爲當今軟件開發人員（工程人員和管理者）所必須的工具。分佈式操作使得基於Client/Server的運算結構跨越於網上客戶機和服務器，ClearCase的先進功能直接解決了原來開發團隊所面臨的難以處理的問題。
軟件開發所面臨的問題包括：對當前多種產品的開發和維護，保證產品版本的精確，重建先前發佈的產品，加強開發政策的統一和對特殊版本需求的處理。通過解決這些問題，ClearCase用資源重用的方法幫助開發團隊使他們所有的軟件建立得更加可靠。 Rational公司的ClearCase是軟件配置領域的先導，它主要基於Windows和UNIX的開發環境。它提供了全面的配置管理──包括版本控制、工作空間管理、建立管理和過程控制，而且無須軟件開發者改變他們現有的環境、工具和工作方式。
ClearCase的核心功能是版本控制，它是對在軟件開發進程中一個文件或一個目錄發展過程進行追蹤的手段。ClearCase對所有文件系統對象（包括文件、目錄和鏈接）增強了版本控制系統功能。可定版本的文件包括源代碼、可執行文件、位圖文件、需求文檔、設計說明、測試計劃、和一些ASCII和非ASCII文件。目錄的版本記錄了整個組織基礎資源的發展狀況，包括源文件的建立、重新命名、重新構造和刪除操作等。 這種版本控制系統提供了先進的版本分支和歸併功能用於支持並行開發。
3.4.1
控制任何文件的版本
ClearCase可以對每一個軟件組件或元件的版本進行維護和控制。ClearCase也可以維護一個非文本文件、目錄和工具的版本。正如：它可以管理庫文件、編譯器、需求文檔、
測試包和數據庫而不僅僅是源代碼。
ClearCase的元件類型可以管理版本內容。用戶可以定義自己的元件類型，也可以使用ClearCase中的預定義類型：文本文件、壓縮文本文件、文件、壓縮文件和二進制增量文件。
ClearCase可以利用增量算法將文本文件存儲在一個特殊結構的文件容器中。ClearCase採用標準的壓縮技術和增量算法存儲一個壓縮文本文件。（這比以往的存儲形式節省了50%―70%的存儲空間。）
這種元件類型文件和壓縮文件可以被用於控制任何操作系統文件──比如，可執行程序、程序資源庫、結構數據庫和結構文檔文件。二進制增量文件類型可以隨時被用於二進制文件格式。
3.4.2
在版本樹中組織元件發展的過程 在ClearCase中，元件版本的組織體現在版本樹結構中。一個版本書的結構可以按目錄結構定製，
還可以包含多層分支和子分支。
在一個典型的開發環境中，很多元件的版本樹結構最初僅包含一個分支，即，
元件的版本排列在同一條線型隊列中。隨着時間的發展，當用戶做一些錯誤修復、代碼的組織、一些實驗性修改或指定平臺的開發時，它們可以給一些相關元件定義子分支，從而脫離主幹進行開發。ClearCase可以支持多級的分支操作，還可以給版本或分支命名。
對目錄和子目錄進行版本控制
ClearCase可以對目錄和子目錄進行版本控制，允許開發者對他們數據的組織發展過程進行追蹤。目錄版本對一些改變進行控制，如：建立一個新文件、修改文件名、
建立新的子目錄或在目錄間移動文件等。
ClearCase也支持對目錄自動進行比較和歸併的操作。
存儲數據在一個可訪問的版本對象類中（VOBS）
ClearCase把所有版本控制的數據存放在一個永久、安全的存儲區中，這個存儲區被稱爲版本對象類（Version Object Bases），項目團隊（或管理者）可以決定它們所需要的VOBs的數量，可以決定什麼樣的目錄或文件需要被維護。VOBs不僅是一個可連接的文件系統而且也是網上的資源──主機可以連接任何數量的VOBs.
ClearCase VOBs的組成模式跟UNIX、Windows NT的文件系統和分佈式的數據庫系統非常類似。ClearCase採用Raima數據管理機制區維護VOB數據庫。當在ClearCase中連接和訪問時，VOB象一個標準的軟件作爲目錄樹的形式出現在客戶面前，包含標準的文件對象：目錄、文件、符號鏈接和硬鏈接。但事實上，文件系統已經有廣泛的版本控制組件：它包含目錄元素、目錄元素版本、文件元素、文件元素版本、VOB動態鏈接和VOB硬鏈接。開發者也可以查看和這些文件系統對象相關的數據。這些數據包括事件記錄，建立審覈以及用戶定義的項如：版本標籤和屬性。
3.4.3
使用常見的檢出/編輯/檢入範例
ClearCase的命令可以控制元素的變化，確保存儲區有序的繁衍並使數據損壞的程度達到最小。ClearCase採用一種檢出/編輯後檢入的範例，類似於傳統的版本控制工具如：RCS和SCCS。ClearCase除了可以進行檢出、檢入以及非檢出操作外，它還可以通過命令設置另外的操作，如：刪除版本、建立/刪除分枝、可按時間順序排列或結構排列順序列出版本歷史、比較版本間的差異，並且可以歸併並行開發的版本。
當開始對於一個指定的文件進行工作時，該文件具有隻讀屬性──這意味着它不能被編輯或刪除。而檢出操作可以對該文件的最近版本形成一個可編輯的拷貝。它無須將文件拷貝到另一區域工作。檢出的註釋可以被提供。當編輯完成後，該文件被檢入，於是在版本樹中形成一個新的版本並且將可編輯的拷貝刪除。爲了檢驗文件的變化，在檢入過程中可以填入註釋信息。文件一旦被檢入，即刻回覆到只讀狀態成爲共享數據，可被所有成員使用。
ClearCase支持兩種檢出，保留以及非保留。保留檢出可以保證版本歷史形成的正確範圍，並且同時只允許一個人做保留檢出的操作。非保留檢出無須保證建立一個成功的版本，如果多個用戶同時對同一元素執行非保留檢出，也企圖進行檢入操作，那麼第一個檢入操作被允許，而其他用戶必須通過歸併操作合併它們的結果。
豐富的註釋信息和版本數據的報表
ClearCase存儲了和文件系統對象相關又截然不同的信息類。這些信息實際上並不包含在對象中，它是一些額外數據。這些數據可以由ClearCase產生，也可以由用戶自己定義。在VOB數據庫中存儲了所有的數據。
ClearCase產生的這種數據信息提供了可靠的、面向文件系統的版本註釋信息。比如：這些數據可以驗證在某一時刻，元素A建立了一個新的版本。用戶定義的數據可以用來表達額外的功能──比如：該文件的版本曾被用於構造應用系統的4.31版。
ClearCase的操作（如：檢出、檢入、和版本歸併）可以建立時間記錄，記錄數據包含這些操作信息。這些記錄被存儲在VOB數據庫中，主要描述了該操作的屬性"誰做的、做什麼、什麼時候、在哪個地方及爲什麼"，比如：敲入命令的人員的ID號，操作的種類，操作的時間，主機名稱及用戶填入的描述。可以通過"lshistory"的命令顯示存儲在VOB中的事件記錄，並且可以通過歷史信息瀏覽器提供的圖形接口觀察VOB中的事件記錄。
用戶可以針對多種目的定義數據，包含分支的名稱、版本標籤、元素任一版本的註釋信息。
ClearCase數據的另一種應用是形成註釋的文本文件。註釋命令可以通過行顯示的形式列出任何一個版本文本文件的內容，這使得我們可以更容易的看到什麼時候在不同的地方做了添加或刪除的操作。
ClearCase也可以針對文件系統對象建立客戶報表。而報表的種類可以由用戶自己定製輸出格式。
3.4.4
通過分支功能支持並行開發
ClearCase支持並行（同時）開發，每一個元素都可以沿着不同的分枝同時發展，即新的版本加到獨立的分支上。ClearCase可以很容易的產生分支，也可以很容易的將不同分支進行合併。這樣一來，即便某一部分的工作被凍結或加鎖，開發者仍然可以繼續自己的工作（如：在軟件集成期）。在這種情況，開發者可以在分支上工作，我們知道， ClearCase的自動化操作和圖形歸併工具可以讓我們很容易的重新集成新的工作。
並行開發是非常重要的，因爲：
（1）它允許不同的項目在同一時間使用同一資源樹。
（2）它將目前不可和其他人員共享的修改成果進行隔離。
（3）它將絕對不可和其他人員共享的修改成果進行隔離（如：已發佈版本中的錯誤修復）。
（4）它使得在軟件集成期間開發工作無需停止，程序員可以先在分枝上開發，以後再集成。
爲了支持並行開發，ClearCase允許進行分支建立，追蹤分支的使用，文件比較，自動歸併功能。
3.4.5
自動的比較和版本間的歸併 並行開發的特點是對同一元素的不同版本進行定期比較，也需要對版本間內容進行歸併。在ClearCase中，對於元素或文本文件進行比較和歸併的操作有兩種：基於字符型和圖形界面型。其中，diff命令執行多文件比較，不執行歸併。而歸併命令可以處理32個"成員"，並把它們生成一個獨立的文件。 ClearCase可以自動辨認歸併選項並實現歸併。ClearCase也可以對需要歸併的項目元素進行定位。如果所有的"成員"（歸併元素）是同一元素的版本，系統會自動確定基礎"成員"，通常是最低版本。此外，ClearCase會記錄基礎版本和某一歸併元素版本間的差異。如果，所有的"成員"間差異互不相同，ClearCase會自動建立歸併版本。如果兩個或多個歸併"成員"文件內容部分不同，歸併功能會提示開發者選擇歸併內容。ClearCase也可以實現反向歸併――從主分支向子分支歸併。
ClearCase的加歸併功能可以在歸併其它分支時選擇指定的版本（那些在分支上自始至終進行變化的版本）。負歸併操作可以刪除部分版本差異，從而形成一個新的版本，該版本除了那些被刪除的變更外包含所有的改變。