常用版本控制軟體簡介

根據檢視網絡上的資料，看到一般的公司使用的版本控制軟體大緻如下：

1.Clear case --------〉中堅級

2.CVS --------〉開源奇葩

3.Visual SourceSafe --------〉入門級 vss

4.PVCS --------〉小工作組級

5 Perforce --------〉

6.CCC --------〉元老級

7.StarTeam --------〉

8.RCS --------〉元老級

9.SCCS --------〉元老級

10.Hansky Firefly --------〉新秀級

11.SubVersion --->CVS改進版本

12.Others（還有一些比較少見或某個公司專用的軟體，如Seapine，北大青鳥的JBCM等）

1．Clearcase是Rational公司(2003年被IBM收購)的一款重量級的軟體配置管理(SCM Software Configuration Managemen)工具。不同于CVS和VSS，Clearcase涵蓋的範圍包括：版本控制、建立管理、工作空間管理和過程控制。從最初的軟體配置計劃，到配置項的确立，從變更控制到版本控制，它貫穿于整個軟體生命周期。 ClearCase支援現有的絕大多數作業系統。ClearCase 安裝、配置、使用相對較複雜，需要進行團隊教育訓練。

2. CVS 是Concurrent Versions System 的縮寫，它是開放源代碼軟體世界的一個偉大傑作，由于其簡單易用、功能強大，跨平台，支援并發版本控制，而且免費，它在全球中小型軟體企業中得到了廣泛使用。其最大的遺憾就是缺少相應的技術支援，許多問題的解決需要自已尋找資料，甚至是讀源代碼。CVS是一個典型的Server/Client端軟體，有 UNIX版本的CVS 、Linux版本的CVS，和WINDOWS版本的CVS，在下載下傳的軟體包中已經包含了Server端和Client端，但是因為我們在工作中一般都是使用Windows作業系統，是以我們可以再下載下傳一個Windows下CVS的Client端軟體WinCVS。在以下網站可以擷取最新版本的CVS。 http://www.cvshome.org。CVS支援遠端管理，項目組分布開發時用CVS。

3.VSS微軟的産品。簡單好用，區域網路中用VSS。用于Team級還可以，企業級不好。僅支援Windows 作業系統。

4.PVCS MERANT 公司的核心産品PVCS，PVCS的最新版PVCS8.0。在PVCS8.0中，過程支援的功能與PVCS進行了內建。看到網上對它的介紹不多，據說曾經贈送給國内很多大的機構使用。主要功能：軟體配置管理;問題管理;過程控制與自動化, 幫助軟體開發組織自動提高軟體産品品質。

5．Perforce是美國perforce軟體公司的軟體配置産品家族，其特點是易用性強，速度快。主要特性【smchina.net 觀點】：安裝、配置和管理非常簡單，安裝過程幾分鐘就可以搞定；基于TCP/IP的客戶伺服器架構，不依賴于其他網絡協定如NFS等；采用流式傳輸協定提高傳輸效率；易用，指令行用戶端容易上手；檔案間分支技術更自然符合開發人員工作習慣；與變更管理內建，并提供開放接口，支援第三方變更管理工具

6．CCC 上個世紀七十年代初期加利福利亞大學的Leon Presser教授撰寫了一篇論文，提出控制變更和配置的概念，之後在1975年，他成立了一家名為SoftTool的公司，開發了自己的配置管理工具：CCC，這也是最早的配置管理工具之一。

7．Borland StarTeam一個用于管理配置和變更的內建環境。主要特性:改善分散式開發團隊的溝通及工作表現;提高對應用軟體開發生命周期的觀測力和控制力;利用現有的技術投資并提高投資回報(ROI);定制滿足機構要求的解決方案. StarTeam和Microsoft Source Code Control接口（API）相容，進而能夠同支援該接口的衆多工具平台進行無縫內建。StarTeam還可以與特定開發工具進行內建，例如 Microsoft、IBM、和Borland的主流開發工具，包括Borland JBuilder、Borland Delphi、Borland C++ Builder。StarTeam還可以與很多第三方軟體內建，進而充分發揮開發機構用于開發、測試和需求等活動的現有投資價值。全部軟體開發資産被妥善地儲存在StarTeam Server中，有助于減少生命周期中不同環節之間的障礙，提高團隊協同工作與資訊共享的效率，進而提升開發機構的投資回報率并加速軟體傳遞市場。

8．RCS是另一種基本的源代碼管理工具,是WALTER.f.Tichy 于1980 年在Indina的 Purdue 大學開發的. RCS和SCCS 類似,也是基于單一檔案的版本維護系統.

9．SCCS的全稱是Source Code Control System。是一種基本的源檔案版本控制工具,它适用于任何正文檔案的版本維護.它基于單一檔案的版本控制,通常,它的軟體儲藏室和要維護的檔案在同一目錄下. SCCS 工作時,有一個專門的SCCS 格式的檔案保留其源檔案的編碼版本,其記錄了足夠的資訊來生成新的版本,并記錄了誰對檔案有修改權,擁有該版本的”鎖”.

10．H a n s k y 公司軟體開發管理套件中重要一員的Firefly，可以輕松管理、維護整個企業的軟體資産，包括程式代碼和相關文檔。Firefly是一個功能完善、運作速度極快的軟體配置管理系統，可以支援不同的作業系統和多種內建開發環境，是以它能在整個企業中的不同團隊，不同項目中得以應用。Firefly基于真正的客戶機/伺服器體系結構，不依賴于任何特殊的網絡檔案系統，可以平滑地運作在不同的LAN、WAN 環境中。它的安裝配置過程簡單易用，Firefly 可以自動、安全地儲存代碼的每一次變化内容，避免代碼被無意中覆寫、修改。項目管理人員使用Firefly可以有效地組織開發力量進行并行開發和管理項目中各階段點的各種資源，使得産品釋出易于管理；并可以快速地回溯到任一曆史版本。系統管理者使用Firefly的内置工具可以友善的進行存儲庫的備份和恢複，而不依賴于任何第三方工具。

11.svn 的主要作者（Fogel 等等）在他們現任公司的資助下開發了SubVersion，用以替代CVS。SubVersion 的設計目的就是針對CVS 的一些弱點進行改進。目前已經有幾個知名的開源項目從CVS 轉向了SubVersion 來儲存源代碼。SubVersion 目前釋出了1.1 正式版，已經相當穩定可靠了。本文隻是對SubVersion 安裝和使用入門的一點引導，以便從未用過版本控制的程式員可以快速上手，先從保護你的個人代碼開始。

CVS SVN VSS 使用對比

版本控制系統裡團隊開發不免要用上CVS SVN VSS ClearCase等工具。至于選擇上，則是根據開發團隊搭建的平台，使用的程式設計語言相關聯。

如果用.net平台開發，VSS無疑首選，盡管它曾經有不經時事的诟病，現在發展的功能也蠻強的。如果有伺服器linux系統，則CVS，SVN都可以選擇。現在SVN大有取代CVS之勢。然而很多古老的程式員還是對CVS情有獨鐘。

如下節選一些網上的對比說明，我作以綜述。當然，真正要弄懂這些版本控制系統，還是要花費巨大工夫學習研究，不可能在baidu或者google幾下就能完成的。

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

Subversion 作為CVS 的重寫版和改進版，其目标就是作為一個更好的版本控制軟體，取代目前流行的CVS。Subversion 的主要開發人員都是業界知名的CVS 專家。Subversion支援絕大部分的CVS 功能/指令；Subversion 的指令風格和界面也與CVS 非常接近。當然，不同的地方正是對CVS 的改進。

二、全局性的版本編号

一個新的版本，并得到一個自增量的版本号N+1，該版本号并不針對某個特定的檔案，而是全局性的、針對整個版本庫的。是以，我們可以将Subversion 的版本庫看作是一個檔案系統或檔案目錄樹的數組。

從技術的角度來說，在Subversion 中，"檔案foo.c 的第5 版本"這個說法是錯誤的；正确的說法應該是："檔案foo.c 在版本庫被修改了5 次，即執行5 次commit 後是什麼樣子？"。顯然，在Subversion 中，版本庫被修改5 次後foo.c 的内容，和被修改了6 次後foo.c 的内容很可能完全一樣，因為版本庫的第6 次修改很可能隻修改了版本庫的其他部分，而并沒有對foo.c 的進行修改。相反，在CVS 中，檔案foo.c 的第1.1 版本和第1.2 版本總是不同的。

Subversion 的全局性版本編号為Subversion 帶來了諸多的優勢：如對目錄或檔案執行拷貝，無論涉及多少檔案，Subversion 不需要對單個檔案依次執行拷貝指令，僅僅需要建立一個指向相應的全局版本号的一個指針即可。

三、目錄的版本控制

CVS 隻能對檔案進行版本控制，不能對目錄進行版本控制，是以CVS 沒有任何關于檔案"移動"（move）操作的概念。當人為進行檔案移動操作時，CVS 隻能注意到，一個檔案在一個位置被删除了，而在一個新位置建立了另外一個檔案。由于它不會連接配接兩個操作，是以也很容易使檔案曆史軌迹丢失。設定 CVS 存儲庫時，必須非常謹慎地為每個檔案選擇準确的位置，因為在設定之後，幾乎就要一直使用這個位置了。

同樣由于CVS 不記錄目錄的版本曆史，CVS 不支援對檔案的"重命名"（rename），人為的對檔案進行重命名會使得命名前後的檔案失去曆史聯系，而記錄曆史本來是版本管理的主要目的。

還有，CVS 不支援對檔案的"拷貝"（copy），人為的拷貝對CVS 而言，隻能看到新的檔案的增加，而不能記錄拷貝源檔案和目标檔案之間的聯系。

綜上所述，缺乏對檔案"移動"、"重命名"、"拷貝"的支援的根源在于CVS 不能記錄目錄的版本曆史，而這些操作在目前的軟體開發過程中經常發生，這正是Subversion被開發并取代CVS 的主要原因之一。

Subversion 将目錄作為一類特殊的檔案來處理（事實上，從檔案系統的角度來看，目錄确實是一類特殊的檔案，當目錄中的子目錄/檔案被删除、重命名、或新的子目錄/檔案被建立時，目錄的内容将發生改變）。是以，Subversion 象記錄普通檔案的修改曆史一樣記錄對目錄的修改曆史，當發生檔案/目錄的移動、重命名或拷貝操作時，Subversion 能夠準确記錄操作前後的曆史聯系。同樣，象對檔案的不同曆史版本進行比較一樣，Subversion支援對目錄的不同曆史版本的比較，清晰展現目錄的變化曆史。

四、原子性送出

從使用者的角度來看，CVS 和Subversion 都支援對多個檔案修改的批量送出，但二者在實作方式上存在本質的差別。

CVS 采用線性、串行的批量送出，即依次地，一個接一個地執行送出，每成功送出一個檔案，該檔案的一個新的版本即被記錄到版本庫中，送出時使用者提供的日志資訊被重複地存儲到每一個被修改的檔案的版本曆史中。

CVS 串行批量送出模式的弊端在于 －當任何原因造成批量操作的中斷時（典型原因包括：網絡中斷、用戶端當機等），版本庫往往處于一個不一緻的狀态：原本應該全部入庫的檔案隻有一部分入庫，很有可能版本庫中的最新版本不能順利編譯，更為嚴重的是，随着其他的使用者執行cvs update 操作，該不一緻性将迅速在開發團隊中擴散，進而嚴重影響團隊的開發效率，并存在品質隐患。另外，假如該批量送出的中斷沒有被及時發現，開發團隊往往要花更多的時間進行軟體調試和排錯。

CVS 即使在批量送出不發生中斷時也會造成不一緻：假設使用者A 啟動一個需要較長時間才能完成的批量送出；與此同時，使用者B 執行cvs update 操作。此時，使用者B 很有可能得到一個不一緻的更新，即使用者B 通過"更新"操作，得到使用者A 的部分修改檔案。

Subversion 徹底消除了CVS 的以上弊端。無論批量送出包含多少檔案修改，隻有當全部檔案修改都成功入庫，該送出才變得有效，才對其他使用者可見；否則，無論任何原因造成中斷，Subversion 都會自動執行"復原"（rollback）操作。換一個說法，Subversion 保證所有的修改要麼全部入庫生效，要麼一個也不入庫，即對版本庫不作任何的修改。這就是Subversion 的原子性送出（atomic commit）。

由于Subversion 的原子性送出特性和全局版本編号方式，當送出成功完成時，一個唯一的、新的全局版本編号産生，而送出時使用者提供的日志資訊與該新的版本編号關聯，隻進行一次存儲（差別于CVS 的按檔案重複存儲）。

五、支援變更集概念

由于Subversion 的所有送出是原子性的，每次成功送出形成的唯一的全局版本号對應此次批量送出的所有檔案修改，也就是說，一個Subversion 版本号其實對應了一個邏輯上的變更集（change set），該變更集可能對應于對一個BUG 的修複，或者對應于對一個已有功能的改進，或者對應于一個新功能的實作。可以說，變更集是一個軟體開發活動的邏輯結果，該變更集可以通過其對應的版本号在軟體開發的其他過程中（如軟體合并/內建過程，軟體釋出管理，變更管理系統，缺陷追蹤系統）被引用。是以，Subversion 将版本管理從單純的、單個的檔案修改的層次通過邏輯上的抽象，上升到更便于了解和交流的開發活動的層次。

六、差異化的二進制檔案處理

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

對于目前的開發團隊，無論是軟體開發，Web 站點的開發，手機等電子産品的研發，需要進行版本管理的不僅是源代碼等文本檔案，還需要管理需求文檔、設計文檔、測試文檔、使用者手冊，圖形圖像檔案，機械/電子設計檔案等諸多的二進制檔案，CVS 顯然不是一個好的選擇。

與CVS 不同，Subversion 采用統一的二進制差異算法（binary differencing algorithm），即對文本檔案和二進制檔案采用相同的差異比較算法，并以相同的方式在版本庫中進行存儲：每次送出後版本庫中隻存儲相對于先前版本的差異，進而可以節省大量的存儲空間。

該二進制差異算法不僅應用在版本的存儲上，更為重要的是，Subversion 對二進制檔案與文本檔案一視同仁，當用戶端需要擷取新的版本時（如執行svn update），在網絡上隻有版本的差異被傳輸，進而大大減少對網絡帶寬的消耗。更多細節參見"七、雙向的差異化－壓縮網絡傳輸"。

七、 雙向的差異化－壓縮網絡傳輸

如上所述，CVS 對二進制檔案不能進行有效的差異化處理。對于文本檔案，CVS 僅僅支援單向的差異化傳輸：從CVS 到用戶端的傳輸是差異化的，即執行cvs update 時，隻有差異的部分從伺服器傳輸到用戶端；而當執行cvs commit 時，無論代碼變化多少，CVS 都需要從用戶端向伺服器完整傳輸被修改檔案的全部内容，不能隻傳輸差異。

相反，無論是文本檔案還是二進制檔案，Subversion 都進行雙向的差異化傳輸，并且差異化内容還要進行壓縮/解壓縮的過程：在伺服器端擷取差異顯而易見，與CVS 類似；Subversion 在用戶端擷取差異的秘密在于 - Subversion 在用戶端的工作拷貝中隐含了每個檔案的一個"隻讀的、幹淨的"副本（該副本隐藏在隐含目錄.svn 裡，通常不可見，該副本還有更多的妙用，參見"十二、更多的本地/離線操作"），通過比較使用者在用戶端的修改和該隐含的副本，Subversion 擷取需要真正傳送到伺服器的差異，并對差異進行壓縮後才進行網絡傳輸。

對CVS 而言，操作的成本（網絡帶寬消耗是最大的操作成本）與被修改的檔案的大小成比例，而與修改本身的大小無關；對Subversion 而言，操作成本隻與修改本身的大小成比例，而與被修改的檔案的大小無關。是以，與CVS 相比，Subversion 消耗更少的網絡帶寬（以用戶端的存儲空間換取更少的帶寬消耗在目前的計算環境下應該是個相當不錯的選擇！）。Subversion 更加适合基于網際網路（或廣域網）進行協作開發的地理上分布的團隊 - 版本伺服器集中、單一；用戶端廣泛分布。

八、高效、快捷建立分支和基線

CVS 和Subversion 都支援分支（branch）和基線（tag），通過分支與合并，可以有效支援大項目的并行開發模式；通過基線管理，可以準确辨別一組檔案的版本，有效進行軟體釋出管理和必要時的曆史回溯。

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

Subversion 的分支和基線是通過執行"拷貝"來建立的：回想一下在沒有引入版本管理工具的時候我們是如何進行所謂的"分支"和"基線"管理的？答案顯然是"拷貝" - 我們通過"拷貝"或"備份"來建立基線；同樣，為支援多個開發人員可以同時進行開發，我們為每個開發人員建立一份"拷貝"。由此看來，Subversion 通過"拷貝"來建立分支和基線顯得非常自然，有點"返樸歸真"的意思。

由于Subversion 的全局版本号特性，Subversion 中分支或基線的建立過程，或Subversion中的"拷貝"過程，真正的操作是在版本庫中建立一個到某一全局版本号的指針（pointer），不再需要針對衆多的單個檔案依次執行操作。是以，該操作的成本為一個很小的常數，與項目大小，版本庫大小，檔案數目的多少無關；并且，分支或基線的建立不需要進行版本的備援存儲，建立立的分支或基線基本不占用版本庫空間，分支的後續存儲空間的開銷也隻與修改的大小有關。

九、內建Apache Web Server，提供更多的特性

Subversion 通過與Apache Web Server 的內建，可以提供基于http/https 協定的版本庫通路機制，進而支援Subversion 跨越防火牆的安全通路。除此以外，Subversion 還可以利用更多的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 系統的依賴，而且能夠更自由的進行創作。上傳、下載下傳變得輕松自如。

Subversion 通過與Apache Web Server 的內建，支援WebDAV 協定，使得業務使用者（business users）或非技術使用者在不安裝任何版本管理用戶端的情況下輕松通路Subversion 版本庫，不改變業務使用者已有使用習慣，支援分布的業務使用者對文檔的評審、修改并實作版本控制，真正将軟體開發的生命周期從開發/技術團隊擴充到項目的全部幹系人（stakeholder），避免通過電子郵件傳遞文檔的混亂與無序、通過Windows 作業系統共享造成的安全漏洞、病毒攻擊、曆史版本被覆寫或丢失、審計困難等諸多典型問題。

十一、更好的沖突辨別與處理

CVS 和Subversion 都支援通過分支與合并進行并行開發，并可以自動檢測到合并時的沖突（conflicts），并在合并結果中以<<<<<< … >>>>>>辨別合并的沖突部分。

在CVS 中，經常會出現由于使用者的疏忽（如，沒有注意到沖突，或沒有完全處理好沖突）而将仍然帶有<<<<<< … >>>>>>沖突辨別符号的檔案直接進行送出（commit），進而在版本庫中産生垃圾版本。

Subversion 有效解決了CVS 的以上問題：Subversion 記錄并保持檔案的沖突狀态，隻有當使用者明确執行svn resolved 指令後，該沖突狀态辨別才被複位，該檔案才能被送出，進而大大減少了将仍然帶有<<<<<< … >>>>>>沖突辨別符号的檔案直接進行送出的可能性。

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

衆所周知，CVS 用戶端的工作拷貝中包含了一個隐含目錄CVS，該目錄中記錄了用戶端需要的一些管理資訊；與此類似，Subversion 的用戶端工作拷貝中也包含了一個隐含目錄.svn，該目錄中同樣記錄了用戶端需要的一些管理資訊，如版本庫URL，目前通路版本号等。

與CVS 不同的是，Subversion 的.svn 目錄中還包含了工作拷貝中每一個檔案的一個"隻讀的、幹淨的"副本。正是由于該副本的存在，使得Subversion 與CVS 相比，可以執行更多的本地/離線操作，即某些操作不需要通路版本庫伺服器，是以不需要存在從用戶端到伺服器的網絡連結，當然也不消耗任何網絡帶寬，這進一步增強了Subversion 對廣域網的友好支援。

Subversion 的以下指令可以進行離線操作：

svn status － 顯示工作拷貝上的本地修改概況；

svn diff －顯示工作拷貝上的本地修改細節，比較修改前後的内容；

svn revert － 撤銷工作拷貝上的本地修改；

十三、 對符号連結進行版本管理

在Unix 檔案系統中，符号連結（symbolic links，包括硬連結和軟連結）是一種重要的檔案系統元素。CVS 不能對符号連結進行版本管理；Subversion 則可以對符号連結進行版本管理。

十四、 中繼資料管理

與CVS 相比，Subversion 增加了中繼資料（metadata）管理機制。即可以對版本庫中的檔案或目錄附加任意的"屬性"（property），并記錄屬性的變化曆史，也就是對中繼資料進行版本管理。一個Subversion 屬性是一個"屬性名稱/屬性值"的二進制組，如"BugNumber= 100"就是一個屬性，可以将該屬性附加到版本N 上，以說明版本N 改正了編号為100的BUG。

Subversion 中繼資料的目的是提供附件的資訊以滿足流程或過程自動化的需要，以增強Subversion 的管理能力和自動化程度。Subversion 自身就通過"屬性"來存儲一些特殊的資訊。一個使用Subversion 中繼資料的例子：可以在一些批處理的腳本程式或Subversion的鈎子程式（hooks）中建立、通路、修改"屬性"中繼資料來滿足流程自動化的要求。

十五 VSS CVS 比較

VSS适合小團隊使用，基本的配置管理功能都有。VSS最大的特點就是部署比較簡單，上手比較快。VSS最大的缺點就是安全性問題，目錄共享、檔案方式存儲等。當然VSS還隻能在Windows下使用。

CVS了解過，應該說特點也很鮮明。首先CVS是開源軟體，根據長期的流傳，已經演變了很多版本，适合于不同的平台。是以，在CVS用戶端上是多種多樣的。其次，CVS的部署稍微複雜點，現對VSS來說，這是其一缺點。最後，CVS在配置管理的理念上，比VSS有所進步。

十六 Vss與Svn 的對比

1. SVN支援重命名，這對 Java開發來說非常重要。

為了得到更好的代碼，開發中需要經常進行重構，重構就經常涉及到檔案的重構名，而重命名中 VSS 中是不被支援的。

2. 開發的時候不一定要鎖定。

一方面導緻重構不友善，另一方面，不能離線開發，使用 SVN 就不同，可以帶回家繼續開發，回來後，送出就行了。

3. 多平台。

可以支援多個平台下的操作

4. 更好的用戶端支援。

Eclipse 中的 VSS Plugin 不如它的 SVN Plugin 好用。一個在 Windows 下用的 SVN 用戶端 TortoiseSVN 也比 VSS 的用戶端好用（VSS 隻有微軟提供的一個 GUI 用戶端）。

5. 更好地與外圍工具內建。

各種各樣的外圍工具（主要是伺服器端），滿足多種需要。如果有需要，也可以自己寫插件或管理腳本，開放的架構，允許我們這樣做。

6. 友善。

一個例子：部署應用的時候，以前的做法是找出一個項目中修改過的檔案，更新到伺服器上去，現在可以在伺服器上執行 svn export 指令，把代碼庫中的最新版本導出，完成部署（也可以替換回老版本）。

7. 速度與穩定性看起來都不錯。

學習它的管理、它的工作方式，是值得的。而 VSS 是一個已經被逐漸抛棄的軟體。如果時間不是多得沒處用，那麼就把時間花在最值得花的東西上面。