爲啥考慮選擇一個版本控制系統呢？由來已久。其實說到版本控制系統，工作的時候順從公司的安排，一直用的是 VSS ，家裏面以前常常使用 VS ，順面也用上了 VSS ，但是到了後來， VSS 明顯不行了，當做 Linux 的工程， Python 工程，或者 Eclipse 中的工程時， VSS 都不太勝任工作，早就想換一個到處能使的版本控制系統了。另外，工作以外其實陸陸續續寫了很多代碼，在博客上發佈的時候常常是用複製粘貼這樣的方式，以前也曾經將一些重要的工程打包，放到 google groups 上去，但是實在是太過麻煩，要方便的話，還是在網站找個項目託管，將所有的代碼直接提交，供大家去取的方式最好，順面將自己的工作之外的代碼編寫方式統一，也更好組織工程的目錄結構。在重裝電腦的時候也省事，不用將 N 大的東西考來考去還怕丟失。在自己家的服務器，臺式機，筆記本 3 者間倒騰代碼也更加方便。
談談目前流行的 RCS 的選擇，基本上現在還在用的版本控制系統分爲 3 種，一種以 VSS(Visual Source Safe) 爲代表，在局域網內使用，第二種以 CVS( Concurrent Versions System ) ， SVN(Subversion) 爲代表在互聯網上使用，第三種以 Mercurial,Git 爲代表，以分佈式方式使用，（對應的， CVS,SVN 的使用方式將所有的內容都集中在一臺服務器上，被稱作集中式）可以在互聯網上使用，但是本機也有代碼倉庫，可以本地提交代碼。基本上，將這三種依次的分爲 3 代也未嘗不可。
Wiki 上有個網頁很詳細的列出了衆多流行的 RCS 極其功能比較，《 Comparison of revision control software 》，建議所有在衆多的 RCS 軟件中看的眼花繚亂的人去看看（也許看過後更加亂了）。總而言之我得出的結論是 Mercurial > SVN > CVS > VSS 。
談談選擇，選擇的目的就是在廣泛的方位內使用版本控制系統，拋棄 VSS 本來就是選擇的目的，這裏就不多說了。
CVS 實在算是老牌的版本控制系統了，當年整個開源世界都是靠 CVS 過來的。但是 SVN 是 CVS 開發者特意針對 SVN 缺點開發的產品，出來以後，整個開源世界都換了顏色。。。。典型的就是 Source Forge ，這個最大的開源站點都換了 SVN 後，還有什麼理由使用 CVS 呢？ Google Project Host 出來的較晚，一開始就是使用 SVN 。另外， SVN 比 CVS 強大的地方除了上面的 WIKI 文章，還可以參考本文最後的中文補充材料。 SVN 替代 CVS 的趨勢是不可逆轉的，拋棄 CVS 。
現在就剩下 SVN,Mercurial,Git 了，其實 SVN 已經足夠強大了，這點毋庸置疑，但是爲什麼我們還需要分佈式呢？（ Mercurial,Git 的代碼管理方式）個人工作時的經歷，使我決定使用最新的特性。 SVN 的代碼提交必須首先要能聯網，這也是開源時，不同的開發者在不懂的地方決定的，分佈式的好處就是本地也有代碼倉庫，這樣即使沒有聯網也可以本地提交代碼，然後等待聯網時再去 Merge ， 當然，這是簡單的說明，最大的好處在於，本地也能有一套完整的版本控制系統，在代碼沒有提交到正式的代碼倉庫前享受版本控制的好處，這點的好處非常多。舉 兩個最常見的例子，其一就是一個代碼量適中的工作，你沒有分出版本，工作到一半的時候，很顯然不能提交到正式的庫裏，影響大家的工作，那麼中途你想嘗試改 改代碼，有個本地庫，能讓你更加的自由，其二就是工作已經完成後，但是還沒有來得及測試，中途需要去完成一個更加重要的工作，此時代碼提交到正式庫中還是 不恰當的，假如有個本地的庫的話，能夠先提交，然後無論過了多久後，你再回來，你都能可靠地獲取到完整的代碼，以前工作的時候在 VSS 我就碰到過這樣的情況，然後 1 ， 2 天的工作就在一個自以爲安全的全取上丟失了。因爲上面痛苦的經歷，我決定嘗試使用最新的分佈式版本控制系統，雖然我已經在自己的服務器上好不容易搭建了一套 SVN 服務了，雖然自己的開發機上都已經裝好了 TortoiseSVN 了，雖然分佈式的版本控制系統還太新，以至於還不太完善。呵呵，作爲程序員，就要敢於擁抱新事物嘛。。。。。。。。又想起某句名言， IT 領域最大的特點就是喜新厭舊。。。。。。
最後剩下的就是 Mercurial 和 Git 之爭了，在這兩個 RCS 中選擇還真是痛苦的選擇，因爲各有優勢，就像當年選擇一個除 MFC 以外的 GUI 庫一樣， Qt 與 GTK 的選擇一樣痛苦。（當年最後的選擇是 Qt ）這裏，有幾篇不錯的中文文章《 擁抱 Mercurial---選擇分佈式版本控制工具 》，《 分佈式版本控制工具： git & mercurial 》，《 幾個分佈式 vcs比較 》 ( 文中的 HG 就是指 Mercurial) 對其進行了比較，具體的比較內容這裏結合 WIKI 中的文章總結下：
GIT:
1.
與
SVN
的集成更好。
2.
GIT
是基於內容的跟蹤系統，相較
Mecurial
而言，模型簡單些，因此容易擴展；
3. Linux 和 rails 世界中應用相當廣泛。（ GIT 本身就是 Linus 開發的，這點是自然的，當年 CSDN 上 C 與 C++ 世界最大的口水戰不就是因爲 GIT 全部是用 C 開發，然後某個 Windows 下的 C++ 開發者提出了疑問後觸發的嗎。。。。。。）
4. 跨平臺特性較弱。（可以理解）
5. 命令複雜。。。。。（對應的也許是功能更加強大吧）
6. branch 建立合併功能強大，方便。
Mercurial ：
1. 與 SVN 命令相似，學習代價更小。
2. 跨平臺特性很好。
3. 使用廣泛，文檔很好。
以下是各自獲得的支持列表：
|
Stand-alone GUIs |
Integration and/or Plug-ins for IDEs |
||
|
gitk, git-gui ( Tcl / Tk ), tig, TortoiseGit , qgit, gitg (GNOME/GTK), (h)gct (Qt), git-cola (Qt), Git Extensions (Windows Explorer) |
Eclipse ( JGit/EGit ); Netbeans ( NbGit ); Visual Studio ( Git Extensions ); Emacs ( extension for standard VC); TextMate ( Git TextMate Bundle ); Vim (VCSCommand plugin); IntelliJ IDEA >8.1 ( standard feature ); Komodo IDE ; Anjuta |
||
|
Hgk (Tcl/Tk), (h)gct (Qt), TortoiseHg (Windows Explorer, Nautilus) |
Eclipse ( Mercurial Eclipse ), NetBeans ( [50] ), Visual Studio 2008 ( [51] ), Emacs, Vim (VCSCommand plugin), Komodo IDE |
比較明顯的是， Git 獲得的 Linux 下的支持那是非常多啊。。。。。。
最後，看的越多，越難選擇，兩者都是非常優秀的軟件，相對來說， Git 更加強大，但是因爲自己還是需要在 Windows 下做一些工作的，另外，因爲想在網上找個地方託管代碼， Google 支持 Mercurial 而不支持 Git ，因爲這個緣故，選擇 Mercurial 了。。。。。呵呵，最後的選擇因爲這麼簡單的原因。。。。。。。
另外，對於 E 文不太好的人，提供一篇中文補充材料：
《 版本控制系統簡介 RCS/CVS/Subversion 》向我們講述了 CVS 的特性， SVN 比 CVS 強大的地方 ，以及一些 SVN 的缺點。
http://blog.csdn.net/vagrxie/archive/2009/09/23/4582457.aspx