hedafighter0 2007-04-14
昨天(周五)大家下班后,一个人留在公司,把核心产品开发团队使用了整整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。子曾经曰过:“纠正错误,时间最早,代价越小”。
*请勿不假思索的模仿,这样做会丢失掉这些文件的历史版本信息,如果删除的时候不小心,同时还会把历史上存在过的同类型文件删掉。我这里之所以可以这么做,是因为我们的实际情况对这些二进制文件不需要保留历史信息。