Posted on 2007-04-14 14:54
laogao 阅读(1710)
评论(3) 编辑 收藏 所属分类:
Project Management 、
The Other Side
昨天(周五)大家下班后，一个人留在公司，把核心产品开发团队使用了整整1年的CVS资源库从CVSNT移到了Linux平台下，原本以为会很简单很顺利，因为之前类似的移植并不是没有做过，所以预估的时间包括验证在内是1~2个小时，不过最终却花掉4个小时。怎么回事呢？且听我慢慢道来。
经过1年的积累，资源库有400多M，大大小小的Java项目有206个之多。按照最初的计划，移植只需要原封不动的把资源库目录整个从CVSNT服务器拷贝到Linux服务器即可，所以资源库大小和项目多少本来不是啥大问题，但谁料半路却杀出个程咬金：.jar文件在新的资源库checkout到本地后无法正常使用，这还了得？
仔细一看，乖乖，原本"Binary"的文件，在新的资源库下，却变成了"ASCII -kkv"，不仅是.jar，其他的二进制文件如.jpg, .exe之类的也是同样的问题。第一反应是CVSNT和Unix经典的CVS在处理RCS文件时还是有些不同，以至于原本在CVSNT下文件类别的标记信息如"Binary"在移植过程中丢失了，变成默认的文本类型。之前有朋友提醒的.doc文件移植后无法打开应该也是同样问题。怎么办？一个文件一个文件的改？肯定不现实。
一种方案是把所有出现的二进制文件类型/后缀名找出来，然后在服务器端批量删除(Linux下写个脚本来做这件事并不难)，客户端这边从原资源库checkout最新版本，重定向资源库URL到新的资源库，同步，提交。这招比较狠，但最终没有用，因为在浏览现有资源库时，发现还有不少其他问题，如classes文件夹被加到版本控制中，类似还有.settings文件夹，甚至Thumbs.db，不一而足。时间有限，与其每个Java项目去找一遍，整理出需要删除的文件(夹)清单，然后写脚本，然后强行资源库重定向，不如一步一个脚印把现有资源库的所有Java项目捋一遍，至少心里踏实。于是一狠心、一咬牙，有洁癖的我开始了漫长的"愚公移山"：一个项目接一个项目，遇到Binary文件，服务器删之，客户端checkout后从原来的地方拷贝过来，必要的地方加上.cvsignore，再添加提交。*
经过4个小时的努力，终于大功告成：自动编译脚本正确运行，构建成功，客户端IDE(Eclipse)从新的资源库checkout，编译通过，没有红叉。
后记：自己认为计划得再好的事情，真正去做的时候，总还是会遇到这样那样的问题和意想不到的状况，这件事也告诉我自己其实我的前期准备远不够充分，算是自食其果吧。有没有更好的办法，我觉得肯定有，但是在特定的情况下(时间/效率/目标)，我相信我的方法还是能够让我自己满意的。还有一点提醒所有CVS的用户，不该提交的文件，最好第一时间加到.cvsignore。子曾经曰过：“纠正错误，时间最早，代价越小”。
* 请勿不假思索的模仿，这样做会丢失掉这些文件的历史版本信息，如果删除的时候不小心，同时还会把历史上存在过的同类型文件删掉。我这里之所以可以这么做，是因为我们的实际情况对这些二进制文件不需要保留历史信息。