Posted on 2011-04-13 11:04
幻海藍夢 閱讀(208)
評論(0) 編輯 收藏 所屬分類:
版本管理 、
配置管理
鑒于遷移版本控制系統的工作量比較大（主要是培訓成本），這幾天我們工作室重新調整了下各自對 svn 倉庫的管理權限，理了下以后的開發管理流程。最終決定繼續把 svn 用下去（至少到項目第一階段完成），希望比以前用的更好。
但出于個人興趣，我繼續考察了幾個分布式 VCS/SCM ，并裝了其中幾個玩。個人直覺 Darcs 最好。不過從流行度講，或許 Mercurial 更佳。
雖然近期網上似乎支持 Mercurial 的最多（包括烏龜版也做的最全面），但我還是找到一篇文章支持我的直覺。
Whose Distributed VCS Is The Most Distributed?
他寫的算是有理有據了。
不過這篇 blog 成文于 2006 年 8 月，離現在已有些年頭，在這個訊息萬變的今天，每個活躍的開源軟件都會不斷的發展，大家姑且看之。至于我的個人意見，只是出于直覺，沒什么可參考性。
作者提出了理想的分布式版本控制系統的八點要求，這也正是我想要的：
-
協作的基本模式必須是基于分支。
-
做分支必須很廉價。
-
可以智能的合并分支。
-
每組更改集都不必通過整個更新歷史就能和其他部分合并。
-
分支既是倉庫的副本，分支操作保持有全部的歷史。
-
合并操作也不損失更新歷史。
-
提交、分支、合并操作都可以離線完成。
-
針對大多數應用都盡可能的快。
關于這 8
點的具體解釋，有興趣的朋友可以去讀原文，寫的很清楚。其實對于我，沒必要分這么細。我需要的就是，大家可以基于分支來協作工作，而不是基于單次提交。我
每次向大家工作的集合（主干）做合并操作，應該包含一系列的本地提交。在完成這個功能的基礎上，VCS 應該用起來足夠簡單（簡單的用
pull/push 取代
update/commit），不損失我的工作流程包含的信息（從何時分支，何時合并，中間做了一系列什么修改），且跑起來足夠快。
作者的結論是明顯偏向 Darcs 的，這個觀點倒是可以商榷。不過 svn 顯然達不到大多數要求。這幾天我在 svn
上做了許多分支合并的試驗，發現 svn 很不人性（相比更人性的分布式設計而言）。為什么會這樣？因為 svn
設計之初本就不是基于分支來解決大家的協作問題的。
btw, Darcs 對中文支持可能會有問題，但是可以通過設置環境變量繞開。請參考 Darcs 的手冊中 Character escaping and non-ASCII character encodings 一節設置。
原文：http://blog.codingnow.com/2008/01/version_control_system.html