我们的项目使用cvs进行源代码的版本管理，经过一段时间的开发测试，主版本已经正式上线运行 ，后续开发工作继续执行 ，我在主版本的基础上建立了若干分支来对应后续需要持续上线的不同功能。
不过在合并第一个分支时碰到如下的困惑：由于后续功能修改量较大，并且很多内容都是在上线的代码的基础上进行修改、添加，在经过较长时间的用户测试用户试用后决定正式上线，不幸的是在主版本合并分支的过程中发现自动合并的的代码出现了过多的冲突！由于主版本并不知道分支修改了多少文件，此时需要估计出修改的文件来进行手工合并，这样的工作量比较巨大，并且出错的几率也相对较大，虽然成功合并出一个版本来，但是始终有点手忙脚乱的感觉。我想我描述的场景应该很多项目组可能会碰到，不知道如何才能缓解此种忙乱的分支合并过程呢？还请不吝赐教。
------解决方案--------------------------------------------------------
我们是所有发现的bug都要修改
根据tag提取出来发布就是了，你们的开发版本和发布版本是在一起的吗？
我们很少做分支。
------解决方案--------------------------------------------------------
呃，虽然理论上发布版本打个tag，到时候提取出来就好。
但是实际上为了图省事，都是做好发布包（install shield打的几百M的包），直接丢到p4上。。。。。。。。
开发版本是主线，发布包是分支。我们一般只维护一个分支。都在同一个p4 服务器上。
------解决方案--------------------------------------------------------
版本多了是挺难管理的，不过项目大了做多个分支版本也是必须的。
建议合理安排版本合并的时间，别等到代码改了都快改够50%了才去做，那做起来当然麻烦，也没安全感。比如每周三周五把改过的东西合并两次，完了做好LIST，统计修改的地方。坚持每周都拿出个吧个小时来，到后来上线合并是也就和每周的工作量一样了。
------解决方案--------------------------------------------------------
呃，看错了。
你竟然不同功能就开分支来开发。
应该保持主开发分支只有一个，维护分支（发布后用于小量修改严重问题的分支）倒无所谓，所有维护分支同步合并到主开发分支就可以了。