与恐龙共舞 3 版本管理

版本管理很简单, 也很实用.
曾经风靡一时的cvs, 霸道的clearcase, 后来居上的subversion, 还有最近的新秀mercuriak/GIT/...

很不幸, 我这里碰到了cvs的前辈, 大名SCCS, 有个GUi的客户端叫teamware, 上网搜索一下, 居然没多少信息, 实在太古董了. 估计很快会成为考古学家的新宠.

一知半解的了解:
1. 貌似基于文件的管理. 但又有bringover和putback.
2. 可以全部bringover, 也可以部分的bringover
3. 类似dvcs, 本地拥有所有历史log, 没有压缩, 庞大, 但是概念是分布式的.
4. 因为基于文件, 错误的提交不用命令, 直接删除, 重新bringover
5. 每个文件可以有自己的分支, 和svn的整个库分支不是一个档次.
6. 没有事务, 提交前检查很重要, 慎之又慎.
7. 没有server, 基于文件系统的库.
8. 所有的文件都在SCCS目录下面有对应的的s.xxx, 用来保存历史记录. 历史记录里面的格式很有趣, 显示提交记录, 然后是内容记录, 哪个版本改过什么都在里面.
9. windows下面没有客户端. linux可能要自己编译. sf.net上面有开源项目.
10.图形工具功能简单, 界面难看. 自动化程度那是相当的低
11.teamware是需要银子的.

ok, 是否可以转换成subversion? 否, 因为公司是分布的. 美国公司和国内公司中间网速不算快. checkout需要很长时间. but, 变通办法, 可以提前checkout好, 然后每个人copy成自己的再增量更新会比较快. 提交的时候会比较慢, 要远程提交. branch切换因为涉及比较多的文件, 也会很慢. svn的客户端最成熟, eclipse有插件, 小乌龟也很好用. 切换版本管理, 最重要的就是要保留以前的提交记录!
初步用网上的sccs2svn.py交换了一下, 不成功, 碰到几个问题:
1. too many open files. 貌似脚本使用了比较老的svn api, 每次提交会打开很多历史log. 解决办法, 限制每次提交的文件数量到40个
2. 同步更新问题. 修改python脚本, 记录已经转换成功的版本数, 以后只转换新的提交. 不过walk这个目录也很慢. 俺们有12万次文件提交, 合并下来是8万个版本, 惊人啊, 转换了一天才完成.
3. 转换过程还算顺利, 中间持久化了要转换的版本, 碰到终端后断点续转.
转换成功, 但是每个文件的分支不能保留下来, 可惜.

后续思路: 用mercurial, 原生支持分布式开发, 协作开发. 缺点, 没有权限控制. 库里面可能有不需要的目录文件, 太大.

另外版本转换有个巨大的阻力: 很多的自动化工具都是用脚本写成的, 需要仔细考虑切换过程.

下集预告: 脚本