云风的 BLOG: 版本控制系统再考察

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

Comments

代码管理SVN还是不错的。

本来合并就是件麻烦事，平时勤快点把主分支的变动合并过来，未来合回主分支就轻松。

倒是策划文档管理一直想找一个合适的工具，理想是能有关键字查询，能有历史版本记录，能对比历史版本的区别，最好还能支持策划们习惯的MS的那些文件格式。

Posted by: Spe | (11) February 18, 2008 05:08 PM

我希望不了解新一代版本控制系统的

可以看看这篇对比文章

http://better-scm.berlios.de/comparison/comparison.html

Posted by: muyufan | (10) February 11, 2008 10:16 AM

更换VC的代价太大了...
FreeBSD.org上一篇比较各个VC工具的文章：
http://wiki.freebsd.org/VersionControl

Posted by: bigmonkey | (9) February 11, 2008 01:22 AM

用了很长时间的bzr (bazaar-ng)，觉得挺有效率的。也建议你考察一下这个。:)

Posted by: Felix Wong | (8) February 3, 2008 08:44 PM

对啊。Perforce速度挺快的啊。。

Posted by: Rome | (7) January 30, 2008 10:46 AM

我们公司以前用CVS，今年刚迁移到Perforce，主要迁移原因是CVS的速度太慢。现在Perforce已经用了半个月左右，感觉除了刚开始登陆的时候比CVS慢，在更新代码的时候，要比CVS快很多，特别是那些dll/lib大文件时。以前用WinCVS更新整个工程需要至少半天时间，现在Perforce一个小时不到就可以搞定。

Posted by: Matthew | (6) January 27, 2008 01:12 PM

其实svn只是个工具～重要的是每个人都能养成良好的习惯，我们一直在使用svn，而且效果很好。我们的做法是有一个主干分支，版本必须从主干上出，小功能在主干上直接修改，大功能迁新分支，修改后有版本控制人员合版本，出现冲突由制作人员，修改，制作大功能的时候一般不在主干修改比较频繁的地方修改，或者说制作功能时注意接口的制作，这样合并的时候虽然有冲突但是很少，提交前必须更新代码，提交后必须通知所研发部所有人，测试人员，版本控制人员，大版本提前一天禁止提交，除非发现比较严重的问题，然后就是正式版本制作，测试，加壳，出版本
最重要就是大家要有意识去遵守，凡是不提交的一律不准出版本，凡是提交的一律必须编译通过，提交不通过就要扣业绩，提交上来有问题或者在规定的时间内没有提交也要扣绩效～，时间长了，版本就很流畅

Posted by: ljc | (5) January 26, 2008 04:35 PM

Perforce 对 open source 的项目倒是免费的。

而且 perfoce 的 diff merge 这些 GUI 版工具不错，我偶尔有用到。

今天我们一个参加 freebsd 项目的同事跟我说，perfoce 也赞助了他们的项目，许多家伙在用。不过他放弃了使用，主要原因是网络连接速度有问题，比 cvs 服务器慢多了。

Posted by: Cloud | (4) January 26, 2008 12:00 AM

Perforce貌似满足你的所有要求。只不过不是免费的，用的人很少。

Posted by: Fan | (3) January 25, 2008 11:35 PM

一直在用svn，现在感觉，每次merge代码，尤其是两个以上的svn库代码都有修改时，只能把多份代码都导出来，然后再比较，那叫一个痛苦，~_~|||

Posted by: anders0913 | (2) January 25, 2008 11:05 PM

TortoiseHg没找到rename，只能用命令行的

Posted by: HeavySword | (1) January 25, 2008 10:11 PM