部门版本管理工具的变迁！

        最近给部门搭建了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与项目管理结合的思考。