分散式的版本控制工具

myattitude發表於2008-07-09
分散式

我最早接觸的 SCM 工具是 vss ，但是沒用幾天（換工作到網易後）就遷移到了 cvs 。我自己大約用了一年後，公司集體從 cvs 遷移到了 svn 。領導這次大遷徙的大大說， svn 是一個更好的 cvs （確實是這樣嗎？據說有爭議，但至少我感覺在多檔案版本控制上 svn 比 cvs 方便，因為 cvs 無法保證多個檔案同時提交的原子性）。

前幾年，有人跟我爭論過到底 vss 的加鎖模式好，還是 cvs 的合併模式好。我覺得答案是不言而喻的，懶得爭論。雖然在某些特殊環境上，我們偶爾需要加鎖模式協同工作，但對於程式設計師的協作來說，無疑我們需要並行的工作。

我們在若干年前曾經淘汰過一次加鎖的協作編碼方式，而到了今天，是時候再做一些改變了。或許，分散式的版本控制工具才是未來的發展方向。我想，總有一天，cvs/svn 這類集中式版本控制工具會被淘汰掉的。

說說我的困擾吧，可能很多開發小組也遇到過。

  1. 我們禁止提交不能編譯通過的程式碼，儘量不提交不能測試通過的程式碼。結果，對於很複雜的模組，有人幾乎一個月都沒提交過一次。他總是覺得程式還不太成熟，但幾經修改的程式碼其實從來沒有作版本控制。
  2. 有些模組由兩個人合作編寫，關係非常緊湊。有時候需要在兩人之間交換一些程式碼，為了方便，大家通過程式碼倉庫中轉，結果在倉庫中留下許多未完成的版本。
  3. 程式碼被用筆記本帶回家，結果在家完成的部分無處可以提交。（為了安全，我們的程式碼倉庫不能從外網訪問）
  4. 某人寫了一個模組，總是有 bug 沒有修改完，而不敢提交。這個時候，另一個人希望協助他找問題，卻沒有合適的途徑 share 那段完成了一半的模組。跑過去 XP 一下麼？天哪，為什麼我們這裡每個人用的編輯器都不一樣，還都愛用些特別個性的配色方案呢？

我們嘗試過一些 work around 的解決方法，比如在本地自己建立倉庫。託 TortoiseSVN 的福，這件事在 Windows 下做起來還是很簡單的。可終歸是多個倉庫的管理，用的人始終感覺麻煩，而沒有貫徹下去。

今天有同事問我，分散式版本控制工具到底跟我們現在在用的系統有什麼區別。我想了一下回答說：它的本質就是在原有工具的基礎上增加了一種方便的倉庫合併功能。（哈，我接觸這類東西時間不長，大家就當我胡說）

集中式版本控制工具，總要求你有一箇中心伺服器，提供一個專案倉庫。每個人都必須嚴格保持跟倉庫的內容一致。當專案大於等於 2 人時，往往都會指定一些規則，比如不要提交寫了一半的程式碼到倉庫去等等。結果，這些規則導致了上面我提到的問題。

即使是一個人自己用，有時候也會碰到問題。有一次我回到家，看到老爸（一個老程式設計師）在家做一個自己的小東西。因為我們家有兩臺電腦，我看見兩臺機器上有若干份不同的版本，我便推薦他用 svn 。因為兩臺機器都不是 24H 開機，我便選擇了在 U 盤上建立倉庫。可以設想的到，兩臺機器的 U 盤插入後碟符是不同的，這可真是一場災難啊。

其實大多數情況下，我們要的僅僅是 版本管理 ，並不要求通過這類工具協同很多人修改同一份程式碼。在我們公司，修改別人的程式碼是要通知檔案建立人的。大家都儘量在自己的工作目錄下寫東西。我並不要求分散式的版本控制工具幫我解決開發人員分佈在不同地方的問題，我需要的僅僅是可以更方便的建立私人（或小團體）的分支，可以區域性的提交的問題。這些，只需要一個倉庫合併的特性就做到了。

我比較孤陋寡聞，知道有分散式版本控制工具是從 git 釋出的訊息開始的。有 Linus 的鼎鼎大名在那，應該是個好東西。我想還會有一些跟我一樣，一進入專案開發就兩耳不聞窗外事的朋友，不知道 git 是何物的話，不妨看看 Git 中文教程 。

可惜的是，git 對 Windows 支援的並不好。我們至少還有一半的專案跑在 Windows 下，開發人員則超過一半在用 windows 平臺。聽說其原因是 git 非常依賴檔案系統的一些特性，這些在 Linux 下表現的很好，而 Windows 下特別糟糕。不管具體原因是這個還是別的，我對在公司推廣 git 沒有多少信心。

另一個選擇是 Monotone ，但聽說跟 git 有同樣的問題（對 windows 的支援問題）。畢竟 git 本身就受了 monotone 的很大影響吧（我猜的）。有趣的是，和 Git 一樣 Monotone 也是用 C 寫的。當然這句話其實應該倒過來說，因為 Monotone 是從 2003 年開始的，比 Git 早多了。

關於 Git 和 monostone 對 windows 支援不太好的說法，可以參考這一篇： Mozilla: Version Control System Shootout Redux Redux ，Mozilla 的大大這樣評價：Git is inappropriate for cross-platform. projects due to its UNIX-centric nature; same goes for Monotone.

嗯，既然 Mercurial 是 (Mozilla 的) current favorite (but not the winner) ，我們也可以關注一下。說起來，Mercurial 的命令名很有趣，是 hg 。我花了幾秒鐘才反應過來，Hg 就是汞嘛 :D 。

下面再讓我們看看幾個候選人，Bazaar 的網站上有它和其它幾種工具的比較。雖然有人說它效能不行，但我想那是針對 Mozllia 這種超級專案說的，我想對我們這樣的小東西不會有什麼影響。別的方面看起來很不錯喲。尤其是它宣稱的智慧 rename ，真是太有愛了。

svn 下給目錄 rename 絕對是場災難。如果你不小心沒有直接去倉庫中 rename ，那麼就意味著目錄下所有檔案的 del / add 。而即使你在倉庫上直接操作，所有 client 都會大量的做 del / add 操作。每當這個時候，我都超心痛我的硬碟。

darcs 看起來也不錯，我對 Haskell 本身就有莫名的好感，用 Haskell 寫出來的軟體對我就意味著穩定。雖然我自己不怎麼玩 Haskell 也不太用 Python ，但是若讓我花時間選一門語言玩的話，我會優先試試 Haskell 的。

作為 svn 的老使用者，或許應該多關注一下 svk ，它在 svn 的基礎上增加了一些分散式管理的東西。但是我不太喜歡這種補丁式的解決方案，因為設計總會隨著需求而改變。若是背上太多歷史包袱會讓我有些不詳的預感。

最後可以看看 GNU Arch 。我瀏覽了 arch 的 wiki 中 WhyArch 這一頁，吸引我的是最後兩條：

  1. Arch is lightweight
  2. Arch has a clean and transparent design

不過從 google 搜尋結果來看，我沒覺得 GNU Arch 是個有前途的專案（相比前面幾個而言）。

對於我這樣依然有部分時間在 Windows 環境下苟延殘喘的程式設計師來說，有個好訊息。那就是託開源的福，可愛的小烏龜無處不在。

  1. Mercurial 的烏龜版：TortoiseHg
  2. Bazaar 的烏龜版： TortoiseBZR
  3. Darcs 的烏龜版： TortoiseDarcs

不過就我的歷史經驗，只有 TortoiseSVN 是正宗烏龜，最好用。不用對其它版本烏龜的操作手感抱太大希望。

補充：

下面很多朋友談到，合理的使用 branch 的功能就能解決我碰到的大多數問題。

沒錯，的確是這樣。但是我們現在使用的 svn ，由於各種原因開 branch 都是件很麻煩的事。並不是指操作麻煩，而是管理麻煩。我們沒有專門的程式碼倉庫管理人員，大家比較鬆散。另外，在經過一次安全事故後，公司要求嚴格控制程式碼樹上每個分支的讀寫許可權。最終導致開 branch 成本過高，而很少有人日常使用。

前面提到分散式版本控制工具提供了方便的倉庫合併功能，這個倉庫合併其實就是分支合併。並非 svn 沒有，而是做的不方便。這一點正如 cvs 的一個老問題：如何方便的確定一組檔案的版本，我們可以用 tag 來解決，但終究不如 svn 那樣每次多檔案提交都是單一原子操作來的方便。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14780914/viewspace-374776/，如需轉載，請註明出處，否則將追究法律責任。

相關文章