最近给部门搭建了SVN+Apache的版本管理系统,先前使用VSS进行源码的管理,比较简单,新员工上手也很容易,但是在后期的版本管理上由于功能不足就导致了版本的混乱,因此迫切需要更好的工具来弥补现在存在的问题。
搭建CVS的系统
使用CVSNT+WinCVS,但是经过一段时间考验发现CVS并不适合我们部门的开发模式,主要有以下原因:
1、每个人的修改都可能会导致整个版本出问题,因此为了便于调查版本问题强调每个人都在上传版本后进行Tag。鉴于CVS只能对文件进行管理,因此Tag操作实际上是对每个文件进行Tag标记,由于整个版本在2G多,这样就导致了Tag操作缓慢而且很容易由于同步操作,某个文件被锁而导致Tag操作中断,这样Tag也没有真正的起到作用。
2、CVS的Checkout一个新的版本速度太慢。
3、由于先前VSS的Update将会覆盖本地修改,而CVS则不会,这样就需要大家对CVSUpdate后的文件进行确认(尤其冲突),而大家处理冲突意识淡薄,遇到冲突总是手忙脚乱。
4、CVS对文本文件的处理不尽如人意,在对.def文件的合并上就是比较差。
使用新工具是为了对工作更有帮助,而不是增添负担,因此听了段时间抱怨,开始寻求更好的工具。
SVN+Apache的搭建
开始就想搭建SVN,最终搭建CVS是因为网上形形色色的都是使用CVS来管理,当然尝试一下也让我了解了我们部门的源码管理上需求,来搭建出是大家使用更加舒服、简单、实用的工具。
使用SVN解决了在CVS上Tag太慢的问题,由于Commit一次SVN就会将版本库大版本号升级一次,也直接满足了我们要求每次上必须Tag的需求。
SVN具有完美的回滚操作,先前Tag被中断后,先前的文件已经被标记而中断后以后的文件则没有这个Tag,而SVN却必须每次操作都必须完全完成才会真正Commit到数据库,中途Error则会完全的被执行回滚。这也是SVN采用数据库来进行存贮的优势。
SVN的Checkout版本的速度比起VSS要逊色一些,而比起CVS来要好一些。
目前使用SVN存在的问题
从SVN版本库Checkout下来的版本每个文件除了Work Copy外还有自己的一份Base Copy,由于版本库原先为2个G,这样就导致了Checkout下来的文件夹大小为4个多G,编译完成后就变成了近6个G,太占用硬盘了,使得原本不大的硬盘就更加紧张。
当然这个功能在我前段时候出差的时候发现也是有很大的作用,当我改动某些文件而且忘记了都改了那些地方时,这样的功能可能通过Diff一下Base Copy,使得我对整个版本的修改一目了然。
经历了VSS->CVS->SVN系统的转变,对版本管理理解的同时让我也逐渐的开始考虑项目的管理,受益不浅,下篇写一下Trac与项目管理结合的思考。