实际项目中的困扰：cvs分支合并（分支时间跨度长，修改文件多）,该怎么处理

实际项目中的困扰：cvs分支合并（分支时间跨度长，修改文件多）
我们的项目使用cvs进行源代码的版本管理，经过一段时间的开发测试，主版本已经正式上线运行 ，后续开发工作继续执行 ，我在主版本的基础上建立了若干分支来对应后续需要持续上线的不同功能。
  不过在合并第一个分支时碰到如下的困惑：由于后续功能修改量较大，并且很多内容都是在上线的代码的基础上进行修改、添加，在经过较长时间的用户测试用户试用后决定正式上线，不幸的是在主版本合并分支的过程中发现自动合并的的代码出现了过多的冲突！由于主版本并不知道分支修改了多少文件，此时需要估计出修改的文件来进行手工合并，这样的工作量比较巨大，并且出错的几率也相对较大，虽然成功合并出一个版本来，但是始终有点手忙脚乱的感觉。我想我描述的场景应该很多项目组可能会碰到，不知道如何才能缓解此种忙乱的分支合并过程呢？还请不吝赐教。

------解决方案--------------------

探讨

楼上的，我的意思是说，我们开发了1.0，然后上线了，然后开发2.0

这个时候是不是要搞一个分支呢？

我们是这么做的。如果1.0发现致命bug（普通bug，能不改就不改了），修改1.0的同时，要修改2.0.出2.0版本后，1.0的就冻结起来，不再维护。

所以我们之多1个分支（就是2个版本的东西需要维护）。

你说的tag，我们也用到，比如发行1.0测试版的时候，加一个tag，但是测试版是不维护的，发现问题直接在开发版里修改了。

------解决方案--------------------
呃，虽然理论上发布版本打个tag，到时候提取出来就好。

但是实际上为了图省事，都是做好发布包（install shield打的几百M的包），直接丢到p4上。。。。。。。。

开发版本是主线，发布包是分支。我们一般只维护一个分支。都在同一个p4 服务器上。
------解决方案--------------------
版本多了是挺难管理的，不过项目大了做多个分支版本也是必须的。
建议合理安排版本合并的时间，别等到代码改了都快改够50%了才去做，那做起来当然麻烦，也没安全感。比如每周三周五把改过的东西合并两次，完了做好LIST，统计修改的地方。坚持每周都拿出个吧个小时来，到后来上线合并是也就和每周的工作量一样了。
------解决方案--------------------
呃，看错了。
你竟然不同功能就开分支来开发。
应该保持主开发分支只有一个，维护分支（发布后用于小量修改严重问题的分支）倒无所谓，所有维护分支同步合并到主开发分支就可以了。