版本管理的一个问题

我目前在一家小的金融企业干IT，负责一个项目的版本管理，用svn。
根据svn的思想，目前的具体实践步骤如下：

1、新需求的开发在trunk下完成。
2、bug可以在trunk下修改，也可以在对应的branch下修改，但是改完后必须互相进行合并（merge）操作，使得trunk和branch下都是bugfixed的代码。

3、当项目经理认为trunk下的开发工作已经实现了一定的需求，可以发布一新版本时，经理跟业务部门再次确认即将发布的需求，之后开发组根据最后确定的需求找出各个文件最新的版本，创建分支。

4、开发组根据创建的新分支进行编译，并部署给测试人员测试，同时把初始的分支打第一个标签tag。

5、当测试人员在测试过程中发现有bug时，及时反馈给开发组，开发组可以在对应的branch下更改代码，也可以在trunk下更改，改完后，bug的问题在两边都必须解决（通过合并操作实现）。重新编译，部署给测试人员重测，同时将最新的代码再打分支tag。

6、在测试的同时，开发组可以在trunk下继续进行新需求的开发，之后又可重复步骤3的过程。

7、当测试人员对某个branch下的代码（N项需求）完成了严格的测试，认为可以通过时，开发组再根据部门的程序上线流程，从其branch下最后的tag中取出相应的服务更新到生产。

现在有如下问题：
   发布的版本解决了业务提出的5个需求，测试也是针对这5个需求进行测试，但是测完后即将上线时，业务却又说只需要发布其中的5个需求中的3个，这时他们又没时间来得及重测，如何办？

扇业务一耳光

是只需要还是只能？ 看意思似乎是只能发布3个。

如果客户坚持，只能调整发布时间，重新测试！

只能上3个，又不调整发布时间，说是我们的问题，这种情况有什么方法解决？

在我们公司，业务是老大，it没地位

男人怎么生孩子？
不加时间完的成完不成
还不是技术说了算？

svn如果想不出办法
就只能认了错，延长时间。

认为：业务的问题，哪有这么搞的，计划到临发布了再改变？
我们是人，不是神！
也是项目管理的问题！

搞定不了就往上层捅，一直捅到对方的上层，然后让他们的leader来出面搞定，
这叫“曲线救国”，这种事情在论坛上是搞不定的，因为IT人员面对的不全是技术问题，因为技术永远是跟着XX走的

对头，技术大部分情况下只能解决技术上的问题，这种则属于”游戏规则“的问题...