分布式版本控制（完）

本篇作一個簡單的總結。

先看一下DRCS與傳統SCM之間的比較。雖然DRCS有很多優勢，但是完全取代集中式的SCM還是不太可能的，畢竟是兩個完全不同的思路。

我 曾經樂觀地認為DRCS會取代傳統SCM，但這隻是我個人的體會，我可以很輕鬆地把SVN換成Mercurial，但是並不表示這對所有人都是合適的。令 狐就指出，在他們公司，因為在VSS的基礎上有一整套自己的管理工具和規範，即使明知有更好的選擇，也不太可能就把它換掉的。

除了這種情況以外，對於公司模式的Team Dev來說，還是需要對原始碼有一個集中管理的約束，在這樣的情況下，集中式SCM還是大有作為的。

但是對於個人、小團隊、分布式團隊、特別是開源的Team Dev來說，DRCS還是具有傳統SCM不可比擬的優勢。而且DRCS中的很多優點也是很值得傳統SCM借鑒的。比如靈活方便的分支／合并功能。SVN的分支合并功能實在是太弱了，用過的都知道。

再比較一下Bazaar和Mercurial。雖然前幾篇中也零散地提到，這裡匯總一下。二者在常用功能的操作方面幾乎都是秉承傳統SCM的操作方式，包括幾乎完全相同的操作命令和參數，以及相似的設定檔項目。所以這方面就不說了，只說說二者不同的方面。

Bazaar 的優點是智能重新命名，這個在大項目中進行目錄重新命名時會有優勢，但是這個功能畢竟不常用。Mercurial的重新命名與傳統SCM是一樣的，都是刪除後重 新添加。在操作效能上Mercurial完勝Bazaar，在安裝方便性上也是Mercurial勝出——Bazaar在使用SSH方式進還需要自己安裝 額外的依賴軟體包。

兩種DRCS最大的區別還是在於對遠程Repository的操作方面。二者都支援通過HTTP和SSH兩種方式訪問遠程Repository，但實現方式有所不同。

Bazaar的HTTP方式很簡單，只要在Web Server裡配置一個Directory項目，允許通過HTTP訪問Repository中的.bzr目錄即可。不過Bazaar的HTTP方式只提供讀操作功能，這是它的不足之處。

需 要進行遠程Repository的讀寫操作，還是要用SFTP——FTP over SSH——方式。當然這種訪問方式的實現也很簡單，只要伺服器支援SFTP即可使用。甚至不需要在服務端安裝Bazaar，遠程Repository的操 作（包括初始建立）也全都是在用戶端進行。

Mercurial的情況則要麻煩一些。它的遠程Repository操作的前提是必須在服務端安裝一個Mercurial，遠程Repository也必須在服務端使用init命令建立才可以使用。

首 先是HTTP方式，這需要在服務端運行serve命令，在特定連接埠上提供HTTP服務，然後由實際的Web Server通過mod_proxy等方式代理一下使用。這樣的代價就是需要在服務端消耗額外的資源，但換來的好處是可以提供更強大的功能，而不是像 Bazaar那樣只能讀訪問。

但是Mercurial的SSH方式就有一點不太方便，當然也是因為Windows的緣故，在Linux下還是很方便的。詳細的情況參見上一篇。

結論就是沒有結論～～冏rz

SVN，Bazaar，Mercurial都很不錯，用哪個就看你的實際情況需要了。另，就算是要三個一起用，也不會有什麼大的衝突。

個人的推薦是：SVN＋任何一個你喜歡的DRCS配合著用是個好辦法——用DRCS作小步迭代式的開發，在需要的時候分支或合并，按自己覺得方便的方式（比如固定的周期）進行SVN提交。