« 分布式的版本控制工具 | 返回首页 | 安全的提交密码 »

版本控制系统再考察

鉴于迁移版本控制系统的工作量比较大(主要是培训成本),这几天我们工作室重新调整了下各自对 svn 仓库的管理权限,理了下以后的开发管理流程。最终决定继续把 svn 用下去(至少到项目第一阶段完成),希望比以前用的更好。

但出于个人兴趣,我继续考察了几个分布式 VCS/SCM ,并装了其中几个玩。个人直觉 Darcs 最好。不过从流行度讲,或许 Mercurial 更佳。

虽然近期网上似乎支持 Mercurial 的最多(包括乌龟版也做的最全面),但我还是找到一篇文章支持我的直觉。

Whose Distributed VCS Is The Most Distributed?

他写的算是有理有据了。

不过这篇 blog 成文于 2006 年 8 月,离现在已有些年头,在这个讯息万变的今天,每个活跃的开源软件都会不断的发展,大家姑且看之。至于我的个人意见,只是出于直觉,没什么可参考性。

作者提出了理想的分布式版本控制系统的八点要求,这也正是我想要的:

  1. 协作的基本模式必须是基于分支。

  2. 做分支必须很廉价。

  3. 可以智能的合并分支。

  4. 每组更改集都不必通过整个更新历史就能和其他部分合并。

  5. 分支既是仓库的副本,分支操作保持有全部的历史。

  6. 合并操作也不损失更新历史。

  7. 提交、分支、合并操作都可以离线完成。

  8. 针对大多数应用都尽可能的快。

关于这 8 点的具体解释,有兴趣的朋友可以去读原文,写的很清楚。其实对于我,没必要分这么细。我需要的就是,大家可以基于分支来协作工作,而不是基于单次提交。我每次向大家工作的集合(主干)做合并操作,应该包含一系列的本地提交。在完成这个功能的基础上,VCS 应该用起来足够简单(简单的用 pull/push 取代 update/commit),不损失我的工作流程包含的信息(从何时分支,何时合并,中间做了一系列什么修改),且跑起来足够快。

作者的结论是明显偏向 Darcs 的,这个观点倒是可以商榷。不过 svn 显然达不到大多数要求。这几天我在 svn 上做了许多分支合并的试验,发现 svn 很不人性(相比更人性的分布式设计而言)。为什么会这样?因为 svn 设计之初本就不是基于分支来解决大家的协作问题的。

btw, Darcs 对中文支持可能会有问题,但是可以通过设置环境变量绕开。请参考 Darcs 的手册中 Character escaping and non-ASCII character encodings 一节设置。

Comments

这篇文章看不懂。

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

其实,分布式不是万能的。指望分布式解决代码合并问题非常不切实际。 还是良好的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的原因,是出于出差或者长时间外出的需求。至于固定的团队开发,我想微软的实例就足够说明问题了。


代码管理SVN还是不错的。

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

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

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

可以看看这篇对比文章

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

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

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

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

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

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

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

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

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

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

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

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

Post a comment

非这个主题相关的留言请到:留言本