拥抱Mercurial---选择分布式版本控制工具

Mercurial是一种开源的分布式版本控制工具,目前的最高版本是1.6.0.2。

一、什么是分布式版本控制工具

传 统的版本控制工具(如SVN,CVS,CleanCase等)因其将Code Repository的所有历史信息全部保存在同一台服务器上,而称为集中式版本控制工具。而在分布式版本控制系统(如Mercurial、GIT)中, Code Repository的历史信息的复本被保存在多台机器中,并且一视同仁,没有主次之分,除非根据团队的管理需要而人为指定哪一台机器为Main Repository。

二、从集成式 到到分布式

我们的项目原来使用SVN作为版本控制工具,但已经改为Mercurial。为什么呢?其实,最初的理由非常简单,集中式版本控制太影响开发效率了!(后来所有人都爱上了Mercurial。)

项目之初,很自然地选择了SVN。因为大家都非常熟悉SVN,而且Chicago Office已经建有统一的SVN服务器。可问题出在网络上。北京与Chicago两个Office之间的网络情况一直不是很好,首次检出代码要花上几小时,每次的检入和检出都很慢。终于,有一次网络断了两天,无法检入检出了。

而此时,很多开源的分布式版本控制工具已经发展起来,其中主流的两个就是Mercurial和GIT。所以,决定试用一下分布式版本控制工具。那么选择哪一种呢?

我们考虑了如下几个问题:

1. 现有的SVN Repository是否容易切换到其上?
2. 假如我们不喜欢用它的话,切换回SVN的难度有多大?
3. 会不会由于它而不得不改变我们的开发习惯?
4. 是否团队的每个成员都能快速上手?
5. Cruise是否很难对其提供支持?(因为我们用自己开发的Cruise来做Cruise的持续集成。)
6. 是否容易与IntelliJ整合?(因为我们用IntelliJ开发。)

二、选择Mercurial
 
为什么选择Mercurial呢?

首先,毫无疑问,入选的DVCS只能是GIT和Mercurial。

GIT在某些方面要优于Mercurial,比如:

1. 与SVN的集成更容易一些。GIT只要通过PUSH和PULL就可以完成它了;
2. GIT可以区分commiter和author,这样流程更灵活一些;
3. 一个很少见的特性:可以通过文本编辑器查看并修改ChangeSets的历史(如重排序、删除等),并将其施加于本地的Repository上。在Mercurial中,与这一特性相当的是Queue.
4. GIT是基于内容的跟踪系统,相较Mecurial而言,模型简单些,因此容易扩展;
5. Linux和rails世界中应用相当广泛。
 
不好的一点就是对Windows的支持不怎么样,虽然也有解决方案(如使用Cygwin或msysGit)。
 
而Mercurial也有它的优点,比如:
1. 很容易被SVN的用户所接受(命令很相似);
2. 在所有的平台上都差不多;
3. 文档很不错(有一个PDF,hgbook)。
 
两个都是不错的DVCS,可根据我们最初的几个标准,以及考虑到学习曲线,我们决定使用Mercurial。

---------------------------------------------
小贴士:根据项目的特点选择合适的工具,可以提高开发效率。
阅读更多
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页