Subversion曾经是我们亲密无间的战友，但自从一年前部分团队成员去了美国，我们和Subversion的关系就开始出现了裂痕，首先是将Subversion服务器架设在美国后，中国开发人员频繁进行的一些操作变得非常缓慢，本来通过追溯代码历史便可找出原因的问题，却因为网速缓慢，导致开发者将大量的时间耗费在等待服务器响应，而不是分析问题上。其次，由于缺乏IT基础设施方面的投资以及完善的备份策略，数次因为网络原因或者服务器宕机，导致团队无法从中国访问版本管理服务器，正常的提交、更新操作都无法进行，最严重的是版本管理服务器曾经在发布之前出现故障，导致服务器上的数据不得不回滚到九天以前，给发布带来了很大的风险。

　　从现象上看，版本管理服务器不在本地是遭遇速度瓶颈的主要原因，本质却是由于版本管理工具不能很好的根据团队的规模和结构伸缩。对我们而言，比较理想的版本管理解决方案是在中美两地架设服务器，加快各个操作的执行速度，服务器之间自动同步来平衡两地对于速度和代码集成的要求。然而采用 Subversion 作为版本管理工具，决定了服务器仅能架设在一地。SVK可以解决部分问题，但它的缺陷太多，操作起来非常不便。我们所面临的备份问题则是由于在Subversion的设计中，所有的元数据仅仅保存在服务器上，一旦服务器出现意外，元数据所包含的宝贵信息便无从恢复。之前的教训让我们认识到如果采用Subversion作为版本管理工具，就不能仅仅乐观的假设服务器不会出错，必须有详尽可行的备份计划，通过不断备份来规避风险。

　　Subversion的这些天生缺陷让我们把目光投向了DVCS（分布式版本管理工具），在这个家族中，比较成熟的产品有Git、Mercurial和Bzr，相比之下，由于Mercurial对Linux，Mac和Windows平台有良好的支持，支持通过Web方式访问代码库，并存在成熟的 IntelliJ、Eclipse插件，最终成为了胜出者，时至今日，它已经在我们团队服役超过1年了，从0.9.4到1.1.2，每一次版本的更新，都让我们愈加喜欢这个设计精巧产品。那么较之Subversion，Mercurial究竟胜在哪里？

　　快速可靠

　　Mercurial带给团队的第一个体验就是快，原因很简单，由于DVCS的工作目录与中央仓库（Central Repository）别无二致，同样保存了全部的元数据，那么Subversion需要通过网络完成的操作(诸如提交、追溯历史、更新等), Mercurial可以在离线条件下通过操作本地仓库完成（图-1）。

　　通过减少与中央仓库的通信, Mercurial加快了操作速度，减小了网络环境对团队的影响，非常符合我们的需求。这种速度和可靠性的提高，对于时刻与版本管理工具打交道的开发者是一种非常愉悦的工作体验。此外，包含了全部元数据的工作目录可以在中央仓库出现问题时（图2-b）成为备用仓库（图2-c），而整个过程只需运行一条命令即可。

　　这样，在IS部门修复中央仓库的过程中，开发团队依然可以通过备用仓库交换修订，日常工作在没有中央仓库的情况下依然可以正常开展，中央仓库恢复后，再将宕机期间所有的修订通过备用仓库同步到中央仓库上（图2-d），这套机制可以作为经费和硬件设施有限团队的备份方案。即便中央仓库完全损毁，所造成的损失也非常有限，避免了使用CVCS时将“所有鸡蛋放在一个篮子里”的风险。