当敏捷遇到版本管理（三）

Question

转：我眼看千里

当版本管理遇到敏捷

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

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

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

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

ClearCase人走了，神还在。

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

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

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

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