• 2010-04-14

    当版本管理遇到敏捷(三)

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

    当版本管理遇到敏捷
    当版本管理遇到敏捷(二)

    我终于遇到了一个不用ClearCase的团队。在我到来之前,他们就从ClearCase切换到SVN。我欣喜若狂,准备卷起袖子大干一场。

    一天,我找到一个开发人员了解构建脚本的情况。
    我:构建脚本都写好了吗?
    开发人员:写好了。
    我:都上库了吧?
    开发人员:没有。
    我:为什么?
    开发人员:我要删掉一些旧的东西,但是我没有删除权限。
    我:……

    这番对话让我意识到有不对劲的地方。我开始了新一轮的调研,结果出乎我的意料。这个团队虽然切换到了SVN,但是,他们并没有像我想的那样在使用SVN。

    同团队负责版本管理的人进行交流,之所以要限制删除权限,是怕成员误操作。好像版本管理工具是有历史的吧!不仅是没有删除代码的权限,更有甚者,他们是用锁来保证团队成员不会产生提交冲突。于是,这个团队的成员开发时,会把代码复制到另外一个地方,写完代码之后,通过工具对比,再合并回来,然后,获取锁,提交代码。这恰恰就是我在《当版本管理遇到敏捷》里描述的某些团队使用ClearCase的操作方式。

    ClearCase人走了,神还在。

    之所以采用这种做法,因为在他们看来,把代码提交到版本管理工具中是一件非常严肃的事,不能有丝毫的偏差。因为按照他们之前的做法,一旦出错是要很长时间才能暴露出来的。于是,他们采用了这种“防止犯错”的方法。

    第五项修炼》提到的修炼法则有一条是,今天的问题来自昨天的解决方法。有一种实践叫做“持续集成”,它的目的就是为了快速反馈,尽早发现问题。这种可能引发编译错误的误操作应该第一时间就可以发现。

    还有一个团队,依然在使用ClearCase,他们一年前曾经对比过ClearCase和SVN,得出的结论是ClearCase更好。我看到了这份对比报告,他们的人问我如何评价。我说,把SVN当作ClearCase用,当然没有ClearCase好用了。

    显然,他们要走的路更长。

    分享到:

    历史上的今天:

    反思回报 2005-04-14
    引用地址:

    评论

  • 你好,我看你的这几篇博文主要谈了CC和SVN。我们的版本控制用的是perforce,我比较好奇你碰到过用这个工具的团队么?你觉得这个对敏捷合适么?
    这里有个比较perforce和其他SCM工具的网页http://www.perforce.com/perforce/reviews.html,当然,都是说perforce好话的...
    回复绿波东流说:
    没有接触过Perforce,不敢贸然评价。
    2010-05-10 22:06:26
  • 哦:)到2010了,看来切SVN都做了哈。只不过,物理上切了,精神上还没切过来。
    避免compare,好像与小步的开发节奏也有关系,每次小的修改,应该都能合入代码库。但把握这样的节奏,可能需要一番磨练。
  • 够崩溃的... 现在还有团队存在这种观念.

    没文化,真可怕!