拥抱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。

---------------------------------------------
小贴士：根据项目的特点选择合适的工具，可以提高开发效率。