便于协同工作

　　在日常的工作中，我们常常利用Mercurial灵活的分支合并来共享修改，协同工作。几个月前在印度发布产品时，我需要在新的工作站上安装开发环境，由于代码库庞大而且网速缓慢，克隆中央仓库的操作需要花费数小时才能完成（图3-a），Mercurial的灵活性使我可以将工作站指向已经存有代码的笔记本电脑来执行克隆操作（图 3-b），在数分钟后工作站就完成了全部的克隆操作，之后再将它指向中央仓库（图3-c），即可正常提交/更新代码，大大节省了时间，提高了效率。

　　在另一个场景中，由于我所在团队使用Linux作为开发环境，在急于验证某些功能是否在Windows平台可以正常工作时，我们会将代码在 Linux工作站本地提交，再将Windows工作站的工作目录指向Linux工作站，获取更新（图4-b）。之后，在Windows 平台验证功能，如果功能存在问题，可以修复后再将修订从Windows工作站提交到Linux工作站（图4-c），最终由Linux工作站运行测试并将全部更新同步到中央仓库（图4-d）。Mercurial的分布式特性让开发团队敏捷的分享修订，更有效率的开发。

　　对小步前进友好

　　本地仓库的存在，使Mercurial对小步前进更加友好。小步前进意味着开发者在不破坏任何现有功能的前提下，每次修改少量代码并提交。这两个需求让使用集中式版本管理工具的开发者常常处于两难的境地，”不破坏现有功能“与“每次修改少量代码并提交”意味着存在便于分析的细粒度需求以及开发人员必须掌握增量式的对象建模、重构，数据库设计、迁移等技术。难于小步前进体现的是团队成员经验和技术的欠缺，然而解决这些问题不是一朝一夕之功，本地仓库的存在给了开发者更大的自由，允许开发者频繁提交而无需顾忌是否每一次提交都不会破坏现有功能，在代码经过若干次提交到达稳定状态时再与中央数据库同步。通过使用Mercurial，使得小步前进这个实践得以在团队开展，在大家体会到实践带来的好处后，再追求高质量的小步前进。

　　学习曲线低

　　Mecurial灵活的分支合并策略使我们可以选择与CVCS(集中式版本管理工具如Subversion，CVS等)非常相似的架构（如图-1所示），这样，团队在更换版本管理工具后依然可以工作在相对熟悉的环境中。在(图-1)所示的结构中，开发者需首先架设中央仓库，再从中央仓库克隆出工作目录，在开发过程中，开发者将修订提交到本地仓库，最后，在功能完成后将本地仓库的所有修改同步到中央仓库。除了最后一步，其余步骤和CVCS完全一致，开发者可以很快对Mercurial总体架构建立初步的认识。Mercurial的基本命令与CVS/Subversion非常类似，熟悉CVS /Subversion的团队可以依然工作在熟悉的命令行环境。从结构到命令，Mercurial做到了对CVCS用户友好，降低了学习曲线，让开发者可以相对轻松的跨出从CVCS到DVCS的第一步。如果仅仅想作一下尝试，又或者公司的政策不允许将版本管理工具从Subversion迁移到 Mercurial，Mercurial还提供了HgSubversion插件可供选择，它可以将Mercurial作为Subverion的客户端使用，这样，既可以保留Subversion版本管理服务器，又可以在本地采用Mercurial来享受DVCS的种种好处，使开发者可以非常安全过渡到DVCS环境。

　　总结

　　毫无疑问Subversion是非常优秀的版本管理工具，但是它有自己的适用范围，并不是银弹。抛弃 Subversion，也不因为我们是新技术的狂热分子，而是它无法伸缩来适应团队的结构变化。对于希望尝试DVCS的团队，我的几个建议是：决策者首先要识别团队的痛点，对问题域有清醒的认识，而不能仅仅追赶技术潮流，其次是使用它、慢慢的接受它，如果团队仅仅止于理论方面的学习，各种方案的论证，是无法掌握DVCS并利用它来提高团队效率的，最后整个团队需要持续学习DVCS背后的设计思想，对于问题域的抽象以及丰富的插件的使用方法。这些知识将直接或间接的帮助团队提高进行代码版本管理的能力，更有效律的管理代码。

　　感谢

　　感谢我的同事杨哈达，初悦欣，乔梁和陈金洲在我写作过程中提供的无私的建议和帮助。和杨哈达的讨论让我对于DVCS的理论有了更清楚的认识，初悦欣和我一起重构了插图，乔梁和陈金洲对于文章的结构提出了很多意见和建议。

　　这篇文章是我在工作中从熟悉的Subversion迁移到Mercurial的经验分享，在这个过程中有不适应，也曾经犯了很多错误并获得了许多经验。希望读者能从这篇文章中有所收获，从DVCS在我们团队的实践了解到DVCS可能带给自己团队的价值，更有信心的进入DVCS领域。