[愚公移山] 团队CVS资源库从CVSNT迁移到Linux

昨天(周五)大家下班后，一个人留在公司，把核心产品开发团队使用了整整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。子曾经曰过：“纠正错误，时间最早，代价越小”。

* 请勿不假思索的模仿，这样做会丢失掉这些文件的历史版本信息，如果删除的时候不小心，同时还会把历史上存在过的同类型文件删掉。我这里之所以可以这么做，是因为我们的实际情况对这些二进制文件不需要保留历史信息。

1年时间就已经有200多个JAVA项目，怎么会有这么多？？你们公司厉害。

迁移配置服务器需要很大的勇气，我公司用的还是Firefly，都没有勇气换调。
明知FireFly这个鬼东西不好用，还要坚持用它。据说是老板认为买了Firefly，所以不用浪费。

岂不知道，这样开发不知道浪费了我们多少宝贵的时间。


sean_gao 写道：

呵呵，我觉得200多个Java项目还好啦，可能是我们业务相对比较复杂一点。敢这么迁，前提是毕竟CVSNT和经典CVS存储方式基本还是一脉相承，且之前有过成功从CVSNT移植源代码库到Linux平台的经历。

hiwzg 写道：

做迁移其实风险很大的，特别是时间历史记录问题很难搞。
不过很奇怪，我看到很多svn和cvs以及其他的迁移工具可以很好的完成工作，而cvs和cvsNT的工具反到是没有看得到合适的。
同时我看到你们的项目有206个，我想这里可能也存在一些问题。比如可能有些项目都是一个大项目树上的各个分支，而有些项目则纯粹只是存储型的。我想如果是第一种情况，则首先应该做一个整合，然后迁移。而如果仅仅是存储，则只需要将最终版本直接移到新服务器就可以了。我也只是瞎猜测，希望能得到你的后续说明。

呵呵，这206个项目属于同一个大产品的同一个版本/分支，除了少数是底层框架和第三方类库，其余都是RCP插件，这些插件预备是要被很灵活的拆开和重新组装的，所以很难说怎么整合更合适，至少目前还没有一个大家公认的更好的组织方式，这确实是件很让人头痛的事。

至于历史记录问题，以我实际的移植经历，时间历史记录，乃至branch和tag，都能够正确保留，历史版本也能够正确取回。当然，所有这些现在看来都需要一个前提，那就是不考虑二进制文件。

以前我曾经遇到过一些项目，其关键数据和测试结果都是二进制的文件，结果最后只能做了一个数据库专门记录这些东西。
我猜测基于文件系统的scm系统这个问题可能是通病。

不过我觉得可能你还是需要整合一下的好。因为从你上面说的情况看，整合之后的将不仅仅会减少scm的压力，而且也可以代理设计和复用的提升。

嗯，确实容易让人有这种怀疑和联想。考虑到CVS出现的年代和背景，以及后续开发和更新的滞后，假如它没有太过关注对二进制文件和跨平台移植的良好支持，我觉得也能够理解。不过也许我不是很了解你之前遇到的问题，我使用CVS的感受和你举的例子多少还是有那么点不同：只要不存在不同文件系统和操作系统之间的移植，始终保持在同类系统上跑的话，用户其实感觉不到有任何差别，二进制文件照样OK。



嗯，谢谢你的建议，我们会尝试去寻找更优的方式组织我们的代码。

我最近也需要将CVSNT移植到HP-UNIX下,除了你用的这个方法外，请问还有更好的办法吗?谢谢!

正式移植之前建议多做些测试，看看有没有什么丢掉的信息。

有时间可以看一下CVSNT的官方网站，CVSNT也有for Linux的版本。