擁抱Mercurial—選擇分布式版本控制工具

Mercurial是一種開源的分布式版本控制工具，目前的最高版本是1.6.0.2。

一、什麼是分布式版本控制工具

傳 統的版本控制工具（如SVN，CVS，CleanCase等）因其將Code Repository的所有曆史資訊全部儲存在同一台伺服器上，而稱為集中式版本控制工具。而在分布式版本控制系統（如Mercurial、GIT）中， Code Repository的曆史資訊的複本被儲存在多台機器中，並且一視同仁，沒有主次之分，除非根據團隊的管理需要而人為指定哪一台機器為Main Repository。

二、從整合式 到到分布式

我們的項目原來使用SVN作為版本控制工具，但已經改為Mercurial。為什麼呢？其實，最初的理由非常簡單，集中式版本控制太影響開發效率了！（後來所有人都愛上了Mercurial。）

項目之初，很自然地選擇了SVN。因為大家都非常熟悉SVN，而且Chicago Office已經建有統一的SVN伺服器。可問題出在網路上。北京與Chicago兩個Office之間的網路情況一直不是很好，首次檢出代碼要花上幾小時，每次的檢入和檢出都很慢。終於，有一次網路斷了兩天，無法檢入檢出了。

而此時，很多開源的分布式版本控制工具已經發展起來，其中主流的兩個就是Mercurial和GIT。所以，決定試用一下分布式版本控制工具。那麼選擇哪一種呢？

我們考慮了如下幾個問題：

1. 現有的SVN Repository是否容易切換到其上？
2. 假如我們不喜歡用它的話，切換回SVN的難度有多大？
3. 會不會由於它而不得不改變我們的開發習慣？
4. 是否團隊的每個成員都能快速上手？
5. Cruise是否很難對其提供支援？（因為我們用自己開發的Cruise來做Cruise的持續整合。）
6. 是否容易與IntelliJ整合？（因為我們用IntelliJ開發。）

二、選擇Mercurial

 為什麼選擇Mercurial呢？

首先，毫無疑問，入選的DVCS只能是GIT和Mercurial。

GIT在某些方面要優於Mercurial，比如：

1. 與SVN的整合更容易一些。GIT只要通過PUSH和PULL就可以完成它了；
2. GIT可以區分commiter和author，這樣流程更靈活一些；
3. 一個很少見的特性：可以通過文字編輯器查看並修改ChangeSets的曆史（如重排序、刪除等），並將其施加於本地的Repository上。在Mercurial中，與這一特性相當的是Queue.4. GIT是基於內容的跟蹤系統，相較Mecurial而言，模型簡單些，因此容易擴充；5. Linux和rails世界中應用相當廣泛。 不好的一點就是對Windows的支援不怎麼樣，雖然也有解決方案（如使用Cygwin或msysGit）。 而Mercurial也有它的優點，比如：1. 很容易被SVN的使用者所接受（命令很相似）；2. 在所有的平台上都差不多；3. 文檔很不錯(有一個PDF，hgbook)。 兩個都是不錯的DVCS，可根據我們最初的幾個標準，以及考慮到學習曲線，我們決定使用Mercurial。

---------------------------------------------
小貼士：根據項目的特點選擇合適的工具，可以提高開發效率。