• 2009-03-18

    当版本管理遇到敏捷

    版权声明:转载时请以超链接形式标明文章原始出处和作者信息及本声明
    http://www.blogbus.com/dreamhead-logs/36730487.html

    为什么我们要放弃Subversion

    很早就知道Cruise团队在使用Mercurial(Hg),直到现在这个项目上,我才有机会第一次近距离接触分布式版本管理工具。

    客户的版本管理工具是ClearCase。我们所到的项目组,版本管理工具就变成了Hg。

    为什么是Hg?因为这是先行几个同事的选择,所以,一开始,我并没有仔细考虑过这个问题,我只是下意识的不喜欢ClearCase这种重量级的版本管理工具。随着工作的深入,包括最近开始做一些跨项目组的工作时,我逐渐开始意识到,正是因为当初选择了Hg,我们的工作才得以顺利开展。

    就从ClearCase说起吧!

    如果你用过ClearCase(SourceSafe也一样),你就会知道,要想修改一个文件,你必须先把这个文件Checkout,修改,然后再Checkin。在你Checkout这段时间,别人是不能对这个文件做任何修改的。ClearCase这种工作方式称为悲观锁,道理上来说,它最大程度上限制了文件冲突。但实际上,这种做法极大限度阻碍人们向库中提交代码。

    一个人修改时,其他人是不能修改的,这会把我们本应并行的工作改成串行。当然,我们都是有职业道德的,所以,我们可能选择的一种工作方式是把这些文件复制到另外一个目录,在那个目录里面工作,然后,要提交了,再把代码复制回来。无论如何,这是一种费力的做法。一旦一件事做起来比较麻烦,人们就会倾向于不做,或少做。所以,其结果就是本地堆积了一大堆代码,很长一段时间才提交一次。显然,这与敏捷中提倡的频繁提交是相背离的。

    别以为我为赋新词强说愁,这是我亲眼所见。换上Hg的项目组,提交的频率明显大幅度提高了。基于悲观锁的版本管理工具在敏捷面前成了绊脚石。

    在使用Hg之前,我最熟悉的版本管理工具是SVN,在我经历的项目中,一直也用的很好。甚至我加入这个项目很长时间之后,我一直为这个项目选用Hg而非SVN耿耿于怀。分布式版本管理最让我喜欢的一点是,可以在没有网络的情况下,进行提交,满足我——一个ThoughtWorker频繁提交的心理需求,要知道,我经常会偷偷自己编一些代码。而这个项目,这一点是完全没有必要的,因为大家的开发肯定都是在一个局域网内。加之,分布式版本管理既要提交到本地版本库,又要推送到服务器上,比起集中式管理要多敲一条命令。你知道,我一直以自己是个懒程序员为荣的。

    但是,我们最近进入到跨项目组的工作,分布式管理工具的价值就体现无遗了。因为整个的开发团队有太大的规模,让大家工作在一个服务器上,冲突的概率太大。所以,我们给出了一个分级的方案,也就是说每个项目组有自己的服务器,一段时间把每个项目组的工作同步到整个团队的服务器上。使用分布式版本管理,在不同的服务器上同步代码相对容易很多。有兴趣的话,你可以想想,如果采用集中式的版本管理,这个问题该如何解决。

    原本我想写一篇关于Hg的文章,但胡凯的文章让我觉得没有这个必要了。唯一需要补充的一点是,Hg本身有很强的扩展功能,我在这个项目上就写了一个扩展,使得CC中的符号链接在Hg中得以保持,所以,如果对Hg有更高的要求,自己动手写一个扩展就好了。

    分享到:

    历史上的今天:

    招聘杂感 2006-03-18
    震撼重临 2005-03-18
    引用地址:

    评论

  • 稍微用过一点cc,在自己的工作分支上checkout有问题吗???
  • 悲观锁
    我用了cc这么久,没有发现有人把cc当成串行开发用的!呵呵!
    cc是不太好用,所以cc的二次开发和流程建设的人才有饭吃!嘿嘿!

    貌似在配置工具中,除非特殊行业,cc还是比较有竞争力的!
  • CC配置的比较好也还是可以频繁提交的:),可以把保留选项的勾不要勾上。
    关键不再于使用哪种版本工具,我们要让工具成为人的奴隶。工具总是要不断优化的,我们用CC也是问题多多,把注意力多关注在开发上,也觉得用CC也还好了。CC的版本管理只是他的一小部分,更大的是需求,流程,等管理。

  • 我是杭州电信的宽带,不知道为什么不能访问infoq的站点。是被墙掉了么?
    回复Lei说:
    那你应该去问杭州电信,或者Infoq。
    2009-03-20 13:17:16
  • 我写的关于mercurial的文章
    http://weavesky.com/tag/mercurial/