当版本管理遇到敏捷 【1】
本帖最后由 feiyang10086 于 2010-12-31 12:37 编辑转：我眼看世界
当版本管理遇到敏捷
为什么我们要放弃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有更高的要求，自己动手写一个扩展就好了。
页:
[1]