改进公司代码版本管理工具CCMS及优化开发流程

2010-12-31更新的内容

目前本人在做developer，日常工作中与代码打交道的机会不少。公司使用CCMS对产品进行版本控制，这套系统的工作原理类似于SVN，它的全称可能是叫做什么什么Code Manage System吧？这套系统肯定是公司自己开发的，不管它了，总之用起来有个不太方便的地方，于是打算写个tool来提高一下工作效率。对于CCMS复杂强大的功能我就尽量回避了，但是一些基本概念还是先交代一下为好！

CCMS的基本操作：
setview_cs -p product cs_id进入一个叫做cs_id的节点，当前目录变为/vobs/spa（虚拟的view）；
cleartool co /vobs/spa/dir1/dir2/ABC.tclcheck out 一个文件，当一个文件被check out出来，有且只有你可以修改它；
cleartool ci /vobs/spa/dir1/dir2/ABC.tclcheck in一个文件，当你完成对一个文件的修改后，check in操作会将你更改后的文件更新到代码仓库中；
cleartoolunco /vobs/spa/dir1/dir2/ABC.tcluncheck out一个文件，你将放弃对它的修改，并将它恢复到check out之前的状态；
cleartool lsco列出所有正在被你check out出来的文件；

2012-07-10更新的内容

今年参加了公司安排的shell培训，感觉收货颇多，正好拿这个工具作为练手。如今这个工具已经完成，我继续来这里把这篇博客写完。

下面就进入正题来说说这个tool吧……

按照惯例，首先应该交代一下写这个tool的目的。
CCMS运行在被称为build server的远程主机上，一般通过SSH或Telnet一类的协议访问它。编辑代码的时候我们使用vi，可能是由于个人习惯的原因，我不是很喜欢用terminal上的vi直接在build server上编写代码。一方面是速度慢，另一方面也容易出错，而且用户界面不太友好。另外加之TCL脚本和SLL语言（私有语言）的特殊性，导致了出现笔误时难于排错，工作效率严重下降的情况。因此本人更加习惯在windows上编写代码，尤其是代码量较大的情况。
由于本人特殊的使用习惯（因为CCMS设计的初衷是非常不提倡将代码文件拷来拷去的，这很容易出错并且有可能导致非常严重的后果，所以绝大多数人都是“老老实实”在terminal中修改代码的），故需要将build server上的代码文件传输到windows中，编辑它，比对它，最后将它传回build server。完成这一系列动作的软件我选择的是Beyond
Compare，也有很多人倾向于使用Total Commander，没关系，其实都是大同小异的。当然本文还是以我熟悉的Beyond Compare为例进行叙述，以下简称BC。
大多数build server上都是开启ftp服务的，有些没有开，但它们至少开启了SSH服务，新版本的BC3支持sftp，这让我感到很欣慰。但不论是BC还是别的什么软件，都有一个共同的问题。CCMS将所有代码文件的信息保存在仓库中，用户可以通过setview的方法，进入一个虚拟目录（实际上是一个view），在这个虚拟的目录下找到要修改的文件，完成编辑它们的工作。但是这个虚拟的目录对于任何一个连接到这台server的访问链接来说，都是不可见的。也就是说BC无法找到这个虚拟目录，也无法操作里面的文件。问题由此产生了，我们怎么才能存取到这些文件呢？
按照道理来说，一个虚拟目录里面的文件应该都是link一类的东西，直到你需要编辑它的时候，通过命令才真正创建一个实体，这个实体文件肯定是保存在某个地方的，只是这个位置对用户来说是透明的。如果我去读数十页CCMS开发手册，或许我能找到这个位置。但我还是认为直接操作这些文件存在很大的风险，某些误操作可能会导致CCMS系统产生错误，这是非常危险的事情，因此放弃这个想法是个不错的主意。
问题似乎又回到了原点，不过既然有个虚拟目录可以用，那何不将虚拟目录中的文件手动拷贝一份出来，然后传来传去的，最后再将它拷贝回虚拟目录中呢？事实就是如此，在此之前我试过用“过语法的那个目录（$SPDIR）”里的文件，我用getversion命令将$SPDIR中的文件更新，然后用BC访问它们，最终完成修改后我再将那些文件cp回虚拟目录中。这个方法有效地提高了我的工作效率，但为此我也需要额外记住很多东西（比如一个文件列表用来告诉我哪些文件需要被cp回去），整个过程我需要十分清楚地记得做过的每一件事情，并知道什么操作可以做，而什么操作最好不要做，否则很可能会在不知情的情况下弄丢一些code，这是非常可怕的事情。
话说回来，如果我不怕辛苦，又非常认真仔细，似乎这样做还是很可行的，只是现在我们有更好的做法……

更好的做法就是开发一个这样的tool：
1. 它要封装cleartool命令的常用功能，包括check in，check out，uncheck out，list checked out，还要支持getversion；
2. 它要省时省力，要对用户透明，使用它时没有额外的负担和过多的开销；
3. 它要非常省心，不用使用者记住过多信息，即便忘记了什么也能很快查到；
4. 它要智能一些，要有一定的版本控制能力，要可以帮助使用者避免误操作的发生；
5. 它要方便易用，不受过多约束和限制，要支持多个CS同时操作，且相互没有任何影响。

下面来说说具体设计思路：
很显然这个tool是用在build server上的，因此我选择了bash脚本语言进行编写。这个tool需要在setview_cs之后使用，它先检测当前view的$CLEARCASE_ROOT并用这个信息创建一个workspace，这个workspace用来存储当前view所check out出来的所有文件。很显然对于每个不同的view而言，$CLEARCASE_ROOT都是唯一的，因此他们的workspace也是彼此独立的。

文件的check in都要进行二次验证才可以，不能check in没有被check out出来的文件，也不能check in没有更改的文件，要确保这个，就需要在check out的时候保存一个文件副本，用于做比较。在check in的时候，不但要确认workspace中的文件有改动，还要确认校验文件与仓库中的文件内容一致。

list checked out的功能不但要列出版本库中被check out出来的文件，还要列出workspace下的文件，方便用户第一时间发现问题（他们的内容应该是一样的，如果出现不一致的情况，很可能是用户绕过了我的tool直接操作了cleartool）。

为了避免用户绕过我的tool直接去使用cleartool，我就要想办法阻止用户使用cleartool，或者即便他们这样用了，也不会对我的体系产生破坏，我选择了后者。为了拥有足够的健壮性，我在每一步关键操作（能使代码库发生改变的操作）的时候，都会检查workspace和版本库的状态（包括文件个数以及文件内容），如果发现问题，就终止操作并提示用户。对于批量任务，需要在所有检查都通过时，才开始执行，即要么全做，要么全不做。

还有一个关键的问题，如果用户由于某种原因，直接修改了代码仓库中被check out出来的文件（比如刚接触这个tool的用户，一时忘记正确的操作流程），这是个非常棘手的问题，因为可能的情况是一部分代码改在了workspace下，还有一部分代码改在了代码仓库中。解决这个问题的思路就是，在check out文件的时候，将代码仓库中文件的写权限去掉，这样就可以有效防止用户误操作。当然，每当check
in的时候，还要为文件添加写权限。

开发流程的对比：

1. 传统开发流程：
cleartool check out -> 在仓库中修改文件（需要在线编辑） -> cleartool check in

2. 新的开发流程：（cow为我的tool）
cow check out -> BC同步文件到windows -> 在windows上使用gvim修改文件（可以离线编辑）->  BC同步文件到workspace -> cow check in
额外的好处是，在使用BC同步之前，可以预览文件的改动（因为校验文件的存在，离线也可以对比），这相当于为开发流程增加了额外的inspection环节，它可以进一步大幅降低typo导致的语法错误。