一直以來對于自己的項目都是使用CVS進行管理，聽說Subversion很久了，但是都沒有時間去嘗試。想想時間都是省出來的，于是決定，一天學一點，不多，積累成河嘛。
Subversion和CVS相比，除了包含了CVS的全部特性之外，也加入了新的理念。
新理念
1、路徑、改名、以及文件meta-data也可進入版本控制范圍。
缺少這些特性是CVS被抱怨最多的方面之一，subversion不止對文件內容和文件存放位置加入控制，也對目錄，拷貝，重命名操作加入版本控制。它也允許文件/目錄的相關元數據meta-data和文件/目錄本身一起被版本控制起來，并提供一種機制對文件的執行權限進行控制。
2、Commit動作真正成為原子級的操作了。
直到整個commit動作都成功前不會有任何部分的commit會生效。版本修訂號只是預確認，而不是對文件預確認。(翻譯不出來 -_-;)日志信息將綁定到修訂信息，而不是象CVS那樣冗余的存儲下來。
3、提供Apache網絡服務器選項，支持WebDAV/DeltaV協議。
Subversion可以使用基于http協議的WebDAV/DeltaV協議進行網絡通訊，并由Apache服務器提供源碼倉庫方的網絡瀏覽服務。這為Subversion提供了比CVS更好的協同工作能力，并提供了各式各樣的自由的關鍵特性：授權，基于路徑的授權，線性壓縮，以及基本源碼倉庫瀏覽。
4、獨立服務器選項
Subversion也能提供獨立服務器選項，使用自定的協議（不是每個人都想運行Apache2.x）獨立服務器可以作為系統的inetd服務運行，并提供基本的授權。它也能使用ssh進行加密。
5、建立分支和標簽操作成為不耗時的操作。
這些動作沒理由耗時，所以我們不再讓它們耗時。
6、分支與標簽的實現都是基于底層的拷貝操作，一個拷貝占用一塊固定大小的空間。任何拷貝都可以作為一份標簽；假如你開始對某個版本的拷貝進行commit動作，那它也就成為一個分支。(這與CVS的"分支節點做標簽"方式不同)
7、天然的client/server結構，層次化庫設計。
Subversion從設計之初即采用client/server機構；因此避免了困擾CVS了許久的一些維護性難題。
代碼被構建為一組帶有詳細接口說明的模塊，用以方便的由其他應用程序進行調用。
8、Client/server協議向雙方發送對比差異。
網絡協議利用寬帶有效地發送對比差異給客戶端和服務器端雙方。( CVS只是 server->client,?沒有client->server )
9、資源消耗與數據改變的大小成正比，而不是與數據本身大小成正比一般來說，一項Subversion操作所需時間與操作最終變化的大小成正比。而不是與操作所觸及的整個項目的大小成正比，這是Subversion源代碼倉庫模型的一個特性。
10、有效的處理二進制文件
Subversion對于二進制文件和文本文件的處理同樣有效，因為subversion使用一種二進制差異比較算法來增量存儲那些連續的修訂本。
11、易于語法分析的輸出。
所有Subversion命令行客戶端的輸出都是仔細設計的，可輕松為人所理解，也適于程序自動解析。可進行腳本語言處理將是下一步優先考慮的特性。
好了，開始使用吧。
Subversion到目前的安裝已經非常簡單了。到Subversion網站下載Windows下的安裝文件，簡單的步驟就可以完成安裝，而且安裝程序已經自動注冊Path，直接在命令行模式就可以使用了。
首先初始化Repository，輸入命令:
svnadmin create D:"TestRepository"
然后，把現有的項目的目錄結構以及文件導入到Repository中：
svn import D:"Projects"Project1 file:///D:"TestRepository"Project1 -m “初始化“
用啟動服務
svnserve -d -r D:"TestRepository"
客戶端Checkout
svn checkout svn://主機名/Project1?? (即獲取Project1的項目)
以上都是很簡單的命令。而且上面只用到了一種服務模式，Apache的還在嘗試中。
目前只用到了Subversion的基本功能，就已經感覺不錯了，覺得入門很輕松，幫助文檔也比CVS要好的多。
Subversion也有圖形的客戶端，可以在 TortoiseSVN 找到。
Subversion也VS.Net的插件，可以在AnkhSVN 找到。
TortoiseSVN相信不錯，因為以前用過它的另一個For CVS的工具，可以和瀏覽器結合在一起，非常方便和美觀。
服務
Subversion具有兩種服務模式，一個是作為Apache的模塊，另一個是自定義協議的Subserve服務。作為Apache的模塊，客戶端可以通過WebDAV/DeltaV協議訪問Repository，而使用Subserve則使用
Subversion的自定義協議。
下表是兩種服務模式的比較：
|
功能
|
Apache + mod_dav_sub
|
Svnserve
|
|
驗證方式
|
基于HTTPS的X.509、LDAP、NTLM或其他Apache支持的驗證
|
CRAM-MD5或者SSH
|
|
用戶帳戶管理
|
私有的用戶文件
|
私有的用戶文件或已有的系統帳戶
|
|
授權管理
|
blanket read/write access或單一目錄的訪問控制
|
blanket read/write access
|
|
加密
|
可選的SSL
|
可選的SSH隧道
|
|
交互性
|
可通過支持WebDAV的客戶端訪問
|
無交互性
|
|
Web訪問
|
有限的內置支持，或通過第三方的工具，例如ViewCVS
|
通過第三方的支持，如ViewCVS
|
|
速度
|
稍慢
|
稍快
|
|
初始安裝
|
稍復雜
|
相當簡單
|
啟動svnserve服務
svnserve 是一個輕量級的服務， 使用自定義的協議通過TCP/IP與客戶端通訊。
客戶端通過由 svn:// 或者 svn+ssh:// 開始的URL訪問svnserve服務器。
啟動服務器
端口監控（inetd）模式
如果你打算用端口監控來啟動處理客戶的訪問請求的進程，你可以通過傳入參數-i來啟動：
svnserve -i
當使用-i參數啟動服務的時候，svnserve通過stdin和stdout用自定義協議和客戶端
通訊。同時服務偵聽3690端口。
獨立端口監控進程
使用參數-d啟動服務作為一個獨立的端口監控進程。
svnserve -d
當運行svnserve在獨立端口監控模式時，你可以使用--listen-port=和--listen-host=參數來自定義需要的端口和主機名稱。當前模式默認的端口是3690。
當然，也有第三種方法啟動svnserve，也就是使用“隧道模式”，使用-t參數啟動服務。這個模式要求遠程服務程序，如RSH或SSH，已經成功驗證用戶，并且使用已經校驗的用戶啟動一個屬于該用戶的svnserve進程。當使用該模式提供服務時，要確認啟動的用戶帳戶具備對Repository的讀/寫權限。
設置項目目錄
當svnserve開始運行時，它將會暴露所有的Repository到網絡上。不過，當客戶端需要獲取一個Repository的內容時，需要指定Reopsitory的絕對路徑。例如：一個Repository放在文件路徑
C:/Project Repository/Project1
那么當客戶端訪問時，需要指定絕對路徑：
svn://host/C:/Project Repository/Project1
所以，為了增加保密性，你可以使用參數-r指定需要暴露的Repository的路徑，當用戶訪問時，只需指定Repository的名稱即可。例如上面的Repository，當啟動服務時，使用如下的方法：
svn -d -r C:/Project Repository
那么當客戶端訪問時，則使用
svn://host/Project1
就可以獲取數據了。
內置的驗證和授權
當客戶端連接到一個svnserve進程時，下面的流程就會觸發：
1、客戶選擇一個指定的Repository；
2、服務處理Repository的配置文件 conf/svnserve.conf文件，并且開始執行在其中定義的所有驗證和授權策略；
3、依賴與情形和授權策略：
a)客戶端也許允許匿名訪問而不需要驗證，或者
b)客戶但也許需要在任何時候被要求驗證，或者
c)假如處于"隧道模式"中，客戶端將聲明自己已經可以被外部驗證。
很顯然，如上所說，用戶文件是一個名為svnserve.conf的，放在conf目錄下的文件。
現在我們來看看如何配置這個文件：
這個配置文件放置在Repository的目錄中的conf目錄下，它有兩個節點：
[general]
[users]
其中，[general]的配置信息有：
anon-access = read
auth-access = write
其中表示對于驗證有效的以及沒通過驗證的用戶可以做什么事情。分別有read, write和none
[users]的標簽的配置內容有：
USERNAME = PASSWORD
password-db = passwd
realm = My First Repository
其中表示，用戶名對應的密碼是什么，或者指定一個存儲用戶名和密碼的文件的相對或絕對路徑以及指定了Repository的驗證領域。如果兩個Repository有相同的驗證領域，那么它們應該有相同的密碼數據庫，反之亦然。默認的領域就是指向當前的Repository的路徑，與服務器的Repository的根目錄相關。
幾個版本控制工具的比較:
cvs是開源項目，其功能比vss強大很多，可以支持版本合并，多個分支。而vss是比較簡單和易用的配置管理工具。在這兩個工具的選擇上還是要看是項目決定，一般10個人以下的團隊vss可能更方便一些~~~
cvs是并行版本管理器，開源，可以多人同時修改一個文件，當出現沖突的時候自動合入或者提示；
vss是微軟visual studio中附帶的版本管理器，只能在windows局域網環境下使用。使用一個文件同時只能由一個人來修改的方法來避免沖突。最大的優點是易學，并且跟visual studio可以無縫集成。
cvs,vss 都是版本控制的軟件工具，可以把源代碼或者其他文件的每一次修改的內容都保存起來，算是可以看以前版本的代碼。
vss 基于文件共享的機制，易用性好，安全性不太好。vss 對于同時增加刪除多個目錄的支持很好。分支合并管理也很容易使用，打標簽功能不太好用。vss 基于文件鎖機制，同一時刻，只能有一個人修改同一個文件。
cvs 基于 c/s 結構，也有工具可以讓它 b/s 運行，不過 b/s 速度慢，使用者不多。cvs 安全控制比較好，對于同時增加多個目錄的支持不太好。cvs 中刪除目錄很難。cvs可以同一時刻多人修改統一文件然后合并，不過只支持文本文件；對于 office 或者其他格式的文檔，多個人同時修改同一個文件很難合并，浪費大家時間。我在網上搜索讓cvs支持鎖機制，只有少數文章提到在 server 端用 script 控制，語焉不詳。
總體來說，cvs 功能比vss強。