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。

---

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

http://blog.csdn.net/tony1130/archive/2008/10/24/3137494.aspx