How to use SVN with large teams having one build automation server and one QE team

Question

I have a situation and am a bit confused regarding it.

Here the detail:-

Suppose i have a build automation system Two development teams A and B and a QE Team to verify the builds.

I also have SVN for source control. My trunk is stable and is what is running on production. Now for parallel development I create Two Feature Branches, Abranch for team A's feature and Bbranch for B's feature. Both start woking on their large feature in their branches and every thing looks good. Now Question arises.

1) Where should QE test the features? (I have only one QE server and one QE database)

We opted the Developers should make a small stable releasable sub set of feature and merger that to trunk and continue working on the branch. Build automation will make build including the changes and deploy it on QE server for verification.(seems good so far but..)

suppose Team A make sub feature and merger to trunk. Now as SVN book says

SVN book says

...Another way of thinking about this pattern is that your weekly sync of trunk to branch is analogous to running svn update in a working copy, while the final merge step is analogous to running svn commit from a working copy

Team B take the update of the trunk to there Branch. And after some time they also make there sub featuer and merger to trunk. Now QE is testing Two Sub features in a single build One from Team A and One from Team B.(Still good so far..)

Now for any reason QE decide that sub feature of Team A is not good to go to production, and the say only to release the Team B's task. Now the problem arises as the merge of Team B contain the changes of Team A also (as we go by the SVN book and updated the featue branch of B Team with the trunk when A has Merged their sub feature).

2) How to handle such situations?

Answer 1

Answer is (probably "one of", but with smallest size of headache):

Additional QA-branch, which contain only mergesets (merges from feature-branches) and serve as single source of merges to trunk after passing QA-tests and cross-branches merges. Excluded from releases features (passed QA-tests before) must removed from QA-branch by reverse-merge of corresponding mergeset(s)