鉴于迁移版本控制系统的工作量比较大（主要是培训成本），这几天我们工作室重新调整了下各自对 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