最近在公司实行主干版本和分支版本并行开发，我所采取的策略其实很简单：
1、我先确定下来一个大的版本，如3.3，并确定好这个版本中索要开发的内容
2、基于CVS的版本控制，我在主干上衍生出一个分支版本，分支版本主要是对企业的BUG和周期短的需求进行开发，开发的过程主要也是围绕这两个版本进行
3、我指定专人在每天下班后将当天在分支中修改的代码合并到主干上，始终保证主干的内容包含分支内容

运行的一段时间以来感觉还是比较顺，但是现在感觉最大的问题还是来自代码合并，因为随着分支中修改的东西越来越多，难以避免的会在合并中和主干产生冲突，而CVS对于两个版本之间的合并，处理了的冲突也会每天再处理一次，工作量比较大。

针对上面的CVS问题，计划分两步来处理：
1、充配置管理软件着手，研究SVN等在这方面的处理效果
2、控制分支版本的维护周期

有点乱，先写这些，大家多提意见

据我了解，SVN合并分支也是比较麻烦的

确实是这样，今天我已经放弃了这样使用CVS的合并功能了，冲突一多，不但解决起来麻烦费时，而且还容易死机，建议大家不要轻易尝试这种方法

至于SVN，确实像楼上的所说的那样，并不能从根本上解决合并问题，SVN在合并上面并不会比CVS强大多少

cvs合并代码确实做的不太好，svn也一样，感觉都不如cc的清晰，

想到一个解决办法，不知是否可行：

分支上某个程序改好bug，由程序员直接合并到head上，自己做的当然自己最清楚怎么合并，合并后触发测试人员在head上作一次测试，通过后ok，由专人统一合并的话，代码不是他写的，合并容易出问题。所以建议1个bug完成，触发一次程序员的合并操作和测试人员的验证操作，这样虽然合并频繁，但是维护的周期短，合并起来既容易又准确，并且及时，当然这个需要bug跟踪系统的工作流中支持这个触发操作。