打印

文章

为什么我们要放弃Subversion

作者胡凯发布于 2009年3月16日下午11时3分

社区: Java,; Agile,; .NET,; Ruby
主题: 协作,; 配置管理
标签: 协作技术,; 最佳实践,; 源代码

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

快速可靠

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

图-1

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

图-2

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

便于协同工作

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

图-3

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

图-4

对小步前进友好

本地仓库的存在，使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领域。

作者简介

胡凯，ThoughtWorks敏捷咨询师，近2年一直从事持续集成工具Cruise以及CruiseControl的设计开发工作。对于Web开发，敏捷实践，开源与社区活动有浓厚的兴趣，可以访问他的个人博客进行更多的了解。

相关阅读

[ ThoughtWorks实践集锦（1）] 我和敏捷团队的五个约定。

[ ThoughtWorks实践集锦（2）] 如何在敏捷开发中做好数据迁移。

[ ThoughtWorks实践集锦（3）] RichClient/RIA原则与实践（上）、（下）。

给InfoQ中文站投稿或者参与内容翻译工作，请邮件至editors@cn.infoq.com。也欢迎大家加入到InfoQ中文站用户讨论组中与我们的编辑和其他读者朋友交流。

加入书签: 鲜果+,; digg+,; reddit+,; del.icio.us+,; dzone+; slashdot+

32 条回复

关注此讨论回复

发表人 David Dun 发表于 2009年3月17日上午2时28分

发表人 sai see 发表于 2009年3月17日上午5时2分

发表人胡凯发表于 2009年3月17日上午5时46分

发表人平平刘发表于 2009年3月17日上午8时37分

发表人 jim shao 发表于 2009年3月17日下午2时59分

发表人 Kenny Yang 发表于 2009年3月17日下午12时58分

发表人胡凯发表于 2009年3月17日下午7时48分

发表人 Willie Wu 发表于 2009年5月15日上午1时36分

发表人 SiYuan Zeng 发表于 2009年3月17日下午9时13分

发表人胡凯发表于 2009年3月17日下午10时32分

发表人 SG soft 发表于 2009年3月17日下午9时25分

发表人胡凯发表于 2009年3月17日下午10时54分

发表人 Tarzan Wang Tarzan Wang 发表于 2009年7月9日上午10时53分

发表人 Jove Zhong 发表于 2009年3月18日上午4时5分

发表人 Shinson Moon 发表于 2009年3月18日上午11时41分

发表人 gakaki withyou 发表于 2009年3月18日下午12时8分

发表人胡凯发表于 2009年3月19日上午5时59分

发表人 Derek Dai 发表于 2009年3月24日下午12时53分

发表人 Gene Wu 发表于 2009年3月18日下午9时32分

发表人胡凯发表于 2009年3月19日上午5时51分

发表人 Arthur Peng 发表于 2009年3月28日上午1时44分

发表人 pro xuhao 发表于 2009年5月8日上午5时25分

发表人 Alex Xiao 发表于 2009年3月24日上午12时57分

发表人璎珞天色发表于 2009年3月24日上午1时13分

发表人 alux xu 发表于 2009年3月25日上午4时52分

发表人胡凯发表于 2009年3月26日下午9时44分

发表人 Steven King 发表于 2009年3月25日上午2时33分

发表人 LI Daobing 发表于 2009年3月26日上午10时2分

发表人胡凯发表于 2009年3月26日下午9时41分

发表人 Tarzan Wang Tarzan Wang 发表于 2009年7月9日上午10时52分

发表人 wind cheng 发表于 2009年10月28日下午9时54分

发表人 ha lla 发表于 2009年8月12日上午9时4分

按日期倒序排列

返回顶部

又看到Zee哥的强文了，呵呵

2009年3月17日上午2时28分发表人 David Dun

怎么样，Zee，还记得我吗，呵呵

回复

返回顶部

Re: 又看到Zee哥的强文了，呵呵

2009年3月17日上午5时2分发表人 sai see

p2p技术的？

回复

返回顶部

Re: 又看到Zee哥的强文了，呵呵

2009年3月17日上午5时46分发表人 胡凯

是的，Mercurial可以借助点对点的方式交换修订

回复

返回顶部

画图工具用的是什么呀？

2009年3月17日上午8时37分发表人 平平刘

画图工具用的是什么呀？
图画得还不错哟！！！

回复

返回顶部

branch不尽如人意

2009年3月17日下午12时58分发表人 Kenny Yang

好像Hg不支持在一个工作目录中开branch

回复

返回顶部

Re: 画图工具用的是什么呀？

2009年3月17日下午2时59分发表人 jim shao

office 2007

回复

返回顶部

Re: branch不尽如人意

2009年3月17日下午7时48分发表人 胡凯

可以用Hg MQ来做到，但确实没有git的支持强大
好像Hg不支持在一个工作目录中开branch

回复

返回顶部

本地库不是会越来越大吗

2009年3月17日下午9时13分发表人 SiYuan Zeng

那样本地库不是会越来越大吗

回复

返回顶部

Git vs SVN

2009年3月17日下午9时25分发表人 SG soft

个人觉得，当程序员的工作主要是离线式的，自由度要求颇高的，且对集中式的，频繁的CodeReview需求不高的，使用Git挺不错，只需熟记几个常用命令就可以，还可以离线工作。
但是对于团队开发，估计还是SVN较为合适。毕竟对于企业内部这种集中式管理环境，SVN的C/S结构天然适合，至少对于分布式版本管理工具而言的优势，对于这种集中开发的公司，就没有优势：
1、速度：内部网的速度问题可以忽略；
2、可靠：企业内部的SVN服务器，基本都是Raid结构，此外，每日增量备份导致出现问题的可能很小；

回复

返回顶部

Re: 本地库不是会越来越大吗

2009年3月17日下午10时32分发表人 胡凯

你说的对，本地库是会变大，但变大的范围可以接受，我们自己项目的大小约为1.7G，相应的Mercurial本地库大小是450M。对于团队这更多的一种权衡吧，考虑到现在硬盘很便宜，牺牲一些硬盘空间换来稳定性和更好的效率还是比较划算的。
那样本地库不是会越来越大吗

回复

返回顶部

Re: Git vs SVN

2009年3月17日下午10时54分发表人 胡凯

>>>速度：内部网的速度问题可以忽略；
如果团队全在一地，速度问题是可以忽略的，但一个公司的团队如果分布在各个国家，特别是中国和美国，中国和印度之间的链接速度还是比较慢的。否则也不会有我在协同工作一节谈到的故事了。

>>>可靠：企业内部的SVN服务器，基本都是Raid结构，此外，每日增量备份导致出现问题的可能很小；
这个还是看企业的资源了吧，不可一概而论。

不过不论是Git还是Mercurial都提供了对svn的支持， gitSvn和hgSvn可以保持集中式的SVN环境的同时，在本地使用DVCS

个人觉得，当程序员的工作主要是离线式的，自由度要求颇高的，且对集中式的，频繁的CodeReview需求不高的，使用Git挺不错，只需熟记几个常用命令就可以，还可以离线工作。
但是对于团队开发，估计还是SVN较为合适。毕竟对于企业内部这种集中式管理环境，SVN的C/S结构天然适合，至少对于分布式版本管理工具而言的优势，对于这种集中开发的公司，就没有优势：
1、速度：内部网的速度问题可以忽略；
2、可靠：企业内部的SVN服务器，基本都是Raid结构，此外，每日增量备份导致出现问题的可能很小；

回复

返回顶部

收费的版本控制软件Perforce也不错

2009年3月18日上午4时5分发表人 Jove Zhong

我们Team用的是这个，可以在各个地区建立服务器，本地程序员只需要连本地的服务器。服务器之间做proxy和备份
perforce的branch功能和revision管理很不错。一张revision graph很清楚的表示这个文件跨越多少分支已经被重构的历史

回复

返回顶部

SVN加NetBeans本地历史，非常实用。

2009年3月18日上午11时41分发表人 Shinson Moon

SVN配合NetBeans的本地历史，非常实用。

回复

返回顶部

请问GIT如何呢

2009年3月18日下午12时8分发表人 gakaki withyou

GITHUB的网速国内已经算是蛮快了我觉得比CODEPLEX 啦 SF.NET google svn都要快

回复

返回顶部

SVN的一个问题是速度慢

2009年3月18日下午9时32分发表人 Gene Wu

如果远程访问，做几次rebase和merge会要人命。

SVN对很多团队来说已经足够了，支持也很丰富。

回复

返回顶部

Re: SVN的一个问题是速度慢

2009年3月19日上午5时51分发表人 胡凯

如果rebase操作缓慢，大都是由于网络连接比较缓慢，这样无论用什么版本管理工具都会慢，但DVCS的好处是有良好的离线支持, 减少不必要的网络调用。此外，merge操作在SVN上永远是要人命的。

就基本版本管理功能SVN足够了，然而SVN对于branch这一最普遍的开发实践支持太弱。对于帮助开发者有效率的开发和使用版本管理，SVN还离的很远。

如果远程访问，做几次rebase和merge会要人命。

SVN对很多团队来说已经足够了，支持也很丰富。

回复

返回顶部

Re: 请问GIT如何呢

2009年3月19日上午5时59分发表人 胡凯

Git也是非常好的版本管理工具，非常快，而且对于branch的支持也非常强大。但是它限制了开发者所使用的平台。

GITHUB的网速国内已经算是蛮快了我觉得比CODEPLEX 啦 SF.NET google svn都要快

回复

返回顶部

分布式版本管理工具非常适用于分布式开发团队

2009年3月24日上午12时57分发表人 Alex Xiao

我们的情况与作者的描述及其相似，我现在感到十分幸运的是，我的团队在一年多了前也决定使用mercurial。跨地域的网络问题与时差问题是分布式团队时常遇到而又十分头痛的两个主要问题，mercurial极大地减轻了我们在这方面的痛苦。如果你的团队也是一个分布式的开发团队，强烈建议你选择一个类似mercurial的工具；如果你的团队只是本地化的，其实svn也足够用了。

回复

返回顶部

偶棉是分布式使用SVN耶～～～

2009年3月24日上午1时13分发表人 璎珞天色

蜡果。。如果公司不穷。人员又多。还推荐介个咩？？
偶棉的情况是：
1 北京两百人，杭州三百人，零星人员在美国，各地的人会同时频繁修改同一套代码。
2 最大滴一个库目前26G，统共备份量400G，16万个版本，每天提交400多次。开发环境都在Linux下。
3 代码库需要和Bug库，权限工具，项目管理工具集成。换句话说每个上线，发布，回滚，故障，Bug要和历史代码对应。
4 网络靠VPN，备份靠双机，7天全量，10分钟增量。库后台不是用数据库存储滴。只有当修订版本树的数量超过64位机同一目录下的文件数限制，才会出现传说中的SVN崩溃。
性能嘛，用着还行啊，还行

回复

返回顶部

Re: 请问GIT如何呢

2009年3月24日下午12时53分发表人 Derek Dai

Git can run on Linux, Windows, it's a extreme fast, stable and secure DVCS. I transfered my projects from SVN to Git 6 months ago. In projects with over 18 thousand files, check status or commit just spend only 1 second!

回复

返回顶部

权限怎样解决？

2009年3月25日上午2时33分发表人 Steven King

DVCS的权限问题一直是软肋。
楼主说到的SVN服务器崩溃，实在令人不解。。。

回复

返回顶部

Re: 偶棉是分布式使用SVN耶～～～

2009年3月25日上午4时52分发表人 alux xu

其实这个情况Git应该更适合

回复

返回顶部

Re: 权限怎样解决？

2009年3月26日上午10时2分发表人 LI Daobing

git 一般每个子项目一个库，所以问题不大

回复

返回顶部

Re: 权限怎样解决？

2009年3月26日下午9时41分发表人 胡凯

这一章对于如何进行权限控制应该说的比较清楚了

hgbook.red-bean.com/hgbookch6.html#x10-1240006.5

回复

返回顶部

Re: 偶棉是分布式使用SVN耶～～～

2009年3月26日下午9时44分发表人 胡凯

如果把所有的代码作为一个DVCS库，不说性能，单说硬盘空间可能都吃不消，所以这样的情况，个人觉得Perforce或者Subversion可能会比较合适。

回复

返回顶部

Re: SVN的一个问题是速度慢

2009年3月28日上午1时44分发表人 Arthur Peng

不明白说的svn 对branch支持太弱具体指的是什么，svn branch/merge没觉得有什么不方便的

回复

返回顶部

Re: SVN的一个问题是速度慢

2009年5月8日上午5时25分发表人 pro xuhao

去了解一下git吧，再回来用svn就会发现很不方便了。

回复

返回顶部

Re: branch不尽如人意

2009年5月15日上午1时36分发表人 Willie Wu

Hg 有許多外掛可以使用，其中內建的 bookmarks 以及 task extension 使用上與 git 的 local branch 相去不遠。

現在 Hg 的開發社群在討論要如何讓 bookmarks 的紀錄也可以經由 push / pull 來傳遞，加上 partial clone 很可能會於 1.4 版整合進來，我是很看好它的。

Git 功能的確很強大，但我覺得 Hg 也不遑多讓就是，各有優缺點。

回复

返回顶部

多个团队异地开发考虑Mercurial，集中开发考虑SVN，毕竟内网速度不会成为问题

2009年7月9日上午10时52分发表人 Tarzan Wang Tarzan Wang

多个团队异地开发考虑Mercurial，集中开发考虑SVN，毕竟内网速度不会成为问题

回复

返回顶部

Re: Git vs SVN

2009年7月9日上午10时53分发表人 Tarzan Wang Tarzan Wang

多个团队异地开发考虑Mercurial，集中开发考虑SVN，毕竟内网速度不会成为问题

回复

返回顶部

有道理，但是必要性上有待探讨

2009年8月12日上午9时4分发表人 ha lla

现在团队中，svn服务器放在英国，使用VPN连接，速度确实慢了点，但是考虑到，svn提交后的自动编译和测试服务器，并且由于时差，每天白天这里提交代码，晚上紧接着就是英国，每天都执行分支合并，似乎不现实。

回复

返回顶部

Re: 多个团队异地开发考虑Mercurial，集中开发考虑SVN，毕竟内网速度不会成为问题

2009年10月28日下午9时54分发表人 wind cheng

对于多个团队异地的情况，我们用svn mirror解决网速的问题，提交的时候向main server提交(提交的数据量都比较小，所以网速慢点影响不大)，从本地mirror check out。麻烦之处是要自己做main和mirror的switch。而且mirror也起到一个备份的作用。

回复

现有用户：

新用户：

您的社区

特别专题

赞助商链接

文章