云风的 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

这篇文章看不懂。

Posted by: 福利工口姬 | (14) April 16, 2014 04:31 PM

呵呵，可以修改bat文件把程序放在u盘上，随用随装，1秒钟搞定

Posted by: Anonymous | (13) January 2, 2009 03:27 PM

其实，分布式不是万能的。指望分布式解决代码合并问题非常不切实际。还是良好的svn习惯实际得多。对于团体性质的开发，svn类似的scm思想是足够的了。关键是要灵活的运用svn所提供的功能和良好的svn习惯。从上一片博文上看好像博主的公司对分支身怀戒心，不能善用分支，无异于砍掉了svn得手和脚，能好用才怪。要说项目的复杂性，大概没有几个能自称和微软相提并论的了。微软开发windows所使用的scm，就是类似svn的一个系统。(有考证说是perforce的定制版本，但未经官方证实。) 建议博主搜索一下相关资料，借鉴一下微软的庞大项目scm管理方法。其实我也在找分布式的scm，svk算是不错的，但是离一个好的scm还是差很远，也多年没有更新，因此才找到这里来。 svn的作者是强烈反对分布式的，就像他激烈批判cvs的自动日志功能一样。照他的话说：要分布式的人，找svk去吧，反正svn是没这打算的。虽然最近风传svn已经易手给collabnet了，但是就算collabnet想扭转这个方向，恐怕也不是近期内的事情了。我提svn的作者强烈反对的意思，是想佐证一下作者这么设定，是有它的考虑的。当初svn不支持自动在文件中追加修订纪录的功能($log$)让我火冒三丈，因为以前用cvs管理的代码，使用自动日志功能后，每个文件的顶部都包含了该文件的详尽历史修订信息，对于功能追溯非常有用，而且看起来也很专业。我试图去给作者提意见的时候发现已经有很多人提过了，其中不乏长篇大论者和我一样的火冒三丈着，双方的论战很是激烈，以至于作者在在醒目的位置挂出说明，粗鲁的拒绝的针对该问题的任何提议。使用习惯后，我当然不能接受svn作者的思路，还是在svn里尽可能的在文件头部增加自动替换的修订版本信息。后来当产品线丰富起来后，有了若干个OEM版、稳定版、开发版、等等版之后，才尝到了苦头。代码的融合简直是恶梦。每个自动修订的属性都会导致毫无疑义的冲突。这个时候我才理解到svn作者当初的苦楚。我之所以要找分布式scm的原因，是出于出差或者长时间外出的需求。至于固定的团队开发，我想微软的实例就足够说明问题了。

Posted by: whoo | (12) August 4, 2008 02:52 AM

代码管理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

云风的 BLOG

思绪来得快去得也快，偶尔会在这里停留

版本控制系统再考察

Comments

Post a comment