关于版本管理的问题请教

公司一个项目，处于长期性的应用维护阶段，即甲方有需求（或BUG）报过来就开发。用户需求是多个部门都可能提交，每个需求经过设计、开发、测试后就下发生产系统，甲方由于内部原因目前没有阶段性版本的概念，基本上是每个需求都走这个流程（因为谁都觉得自己的需求很重要不能等别人，但最后往往都拖着不测，哎，这就叫甲方……）。
这就使得我们的版本管理很混乱，再加上系统很庞大，以前也一直没有很好的回归测试方法，没法控制每个需求的代码改动对其它需求的影响度。比如先来了个需求A，于是可以开一个分支A进行开发，再来了个需求B再开个分支B，然后分支B在先测试完成后merge到主线然后下发，到这都没问题。然后分支A在测试完成后如果merge到主线的话，怎么保证此时B是正常的呢？B部门的业务人员是不会给你再做一次测试的，因为我们的系统是个渠道业务系统，许多需求是要与多个外部系统进行联调，测试工作的协调是相当复杂的，而且也基本没办法做到自动回归业务测试，只做单元测试又不够全面。流程的不确定性又使得我们没法使用每日构建来及时发现问题，当同时有十几个这样的需求的时候那就很晕了，往往造成很多问题在最后merge后才发现（又不可能把测试安排在merge之后，因为测试周期不确定，可能还没测完其它需求又要merge而且可能还会先下发），有时测试系统没问题下发到生产系统才出现问题。
对用户进行流程改进的引导在短期内还不太可能生效:( 。问问各们对这样的情况有什么看法和建议讨论一下。

为什么每个需求都要创建一个分支？
平凡的创建分支本来就会给你们的开发带来巨大的混乱。
维护阶段的时候主干还在开发吗？
这个其实主要看你们pm的和客户的沟通能力，即使客户的需求A，b一起来，也不能单独搞2个分支进行分开开发，然后再合并进去，而是这边确定一个计划，确定好a，b的需求在什么时候提交给客户，和客户沟通后在同一个branch或者主干上进行开发。然后进行测试发布。

控制起来，对于每一个变更进行必要的评审，看是否对现有生产系统等产生影响，产生什么影响，影响有多大，每一个变更都要跟踪，变更流程也需要控制，基线要打，看了你说的情况，就可以按照时间来打基线，到几号为止，就是一个稳定版本的发布，任何东西都不再添加，所有的bug和变更都迁移到下一个版本去控制。同时可以建立维护版本进行小版本控制。

偶主贴里可能说得不够清晰，客户不可能事先告诉我到几号之前要下发哪几个需求，他们的流程就是一个需求一个需求地走。走完流程的就下发，象2楼说的，AB如果在同一个分支开发，那到时如果客户决定我只下发B不下发A那不就惨了。所以也没法象三楼说的按时间来打基线，客户没有阶段性版本的概念，各个部门都提自己的需求，没有个统一的需求打包版本，这只能从流程上对他们进行引导，如果能做到这样偶就不用这么烦恼了。
偶现在能想到的只能是一个需求一个分支（这对SVN和CVS这种COPY分支的来说要耗费太多的空间了:(）开发测试。然后确认好哪些需求要下发的时候再并入主线再叫他们业务测试一遍然后下发生产系统。这样的缺点就是一要两次测试，二是没法使用每日全系统构建，所以在并入主线的时候可能工作量会较大而且容易冲突出问题。

楼主的问题我在实践中也碰到过，这的确是令人头疼的事啊。不过工具毕竟是工具，不可能帮你解决语义上的问题，如果你在划分分支的时候把耦合度高的两个功能点分成两个分支开发，那发生问题的可能性的确很高，而如果将耦合性较小的功能分而治之，可能就会好很多了。

实际上我觉得出现这样的问题的根本原因还是你们开发部对需求部门的交涉力太弱，应该据理力争，从需求阶段就积极平衡各方利益（包括你们部门自身的利益啊）

最后：楼主所说的“这对SVN和CVS这种COPY分支的来说要耗费太多的空间了”，实际上SVN中的分支完全不耗空间，只是记录一个指针而已，消耗常数时间和空间，你可以不把所有的分支都check out到本地，而用svn switch去切换你的工作目录

我觉得分支A在merge进来的时候，需要把B再做测试。B部门不给，A部门要给。