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

Question

转：我眼看千里

当版本管理遇到敏捷

如果我是一个咨询师，我就要面对一个叫做ClearCase的版本管理工具，
我是一个咨询师吗？是的。
所以，我还得面对ClearCase。

虽然，我曾经在不少人面前举证过ClearCase的种种不是，但当我出现在一个新团队的面前，我还要想办法，让他们相信我说的是真的。

几个月前，我的说辞是ClearCase在乐观锁问题上表现不佳。这次，我遇到了一个告诉我ClearCase支持乐观锁的人。其实，我也知道ClearCase支持乐观锁，但我就是不喜欢这种把人教坏的重量级工具。我以乐观锁的方式试用了ClearCase，结果是更加坚定了我的信念。

ClearCase在修改一个文件之前，必须先将文件CheckOut出来，乐观锁的方式只是说，多个人可以同时CheckOut一个文件，但无论如何CheckOut的动作是不可或缺的。作为一个开发人员，我编写代码之前，是无法完全预期我要改哪些代码的，所以，我不可能在每次修改之前，把所有用到的代码都CheckOut出来的。如果在写代码的过程中，遇到了一个要修改的文件，就要做一次CheckOut，想一下，我都会觉得麻烦。工具是用来为人服务的，而不是添乱的。

Subversion相较于CVS的一个重大进步是对重构的支持，比如文件改名，历史仍得以保存。ClearCase在这方面做得也很好，也能在文件改名的情况下保留历史。但是，它的修改操作是直接在服务器上完成的。在敏捷的团队里面，CI纪律要求所有人必须在本地修改验证完成才能提交代码。直接修改服务上的内容，对CI来说，是非常不安全的，因为很有可能会造成提交的不完整。不完整的提交结果就是，持续集成会失败，而这种失败实际上是一种假失败。经常性的假失败，就会造成团队不再信任CI，CI也就成了无人关心的破窗户。

与不完整提交相关的另外一点是原子提交。如果不支持原子提交，就有可能出现提交过程中，出现失败，只有一部份文件提交成功，造成不完整提交。不完整提交的后果，前面已经说了。ClearCase恰好不支持原子提交。

关于ClearCase，有一点我不得不说，虽然与敏捷可能并不直接关系：符号链接。ClearCase中的符号链接同操作系统的符号链接是异曲同工的。正是因为ClearCase支持，我所接触的团队居然可以把符号链接用到难以想像的地步，漫天遍野的符号链接，却从来没有仔细考虑过重新组织一下文件结构，让代码做到真正意义上的只有一份。或许，这不应该算是工具的错。SVN也支持符号链接，但至少我在使用SVN从来没有使用过。工具也是俱备很强引导性的，这也就是为什么我说工具会把人教坏。在前一个项目里面，因为开发团队已经在开发之中，我们不得已用Hg的钩子这种旁门左道解决问题。再次面对它，我们有机会用正道——调整文件组织，彻底的解决这个问题。

说起来，其实只是一些地方的细微差别，但就是这些细微的差别，就会让人用起来很不舒服。失之毫厘，谬以千里。