Subversion branches and release plan

Currently we are following a simple release plan for our projects as follows;

Developers committed changes to subversion repository.
Build changes to QA server.
Build changes to production server.

The issue is we use one single source code set in SVN trunk for all these steps.

Therefore we cannot control QA server release (ex: avoid some requirements).

We have very complicate release occurrence as some days we have to release 5-6 times to the QA server.

I guess using a subversion branches I can overcome this issue. Hopefully I can create a separate branch for QA/live server release and I can merge necessary changes from head/trunk.

Or is this other way around? Keep head/ trunk version for QA/ live server release and create a branch for development commits.

What is the correct way?

Please let me know whether there is any better way/tool for handle this situation.

Thanks.

Solution

There is a quite popular approach to branches in SVN. It's described here: http://svnbook.red-bean.com/en/1.7/svn.branchmerge.commonpatterns.html

In my project (one-person project with a separate release cycle) I use both release and feature branches and have no problems.

Exact branch policies may vary, here is what works for me:

Trunk (only one): all automatic tests pass, contains only completed features and bug fixes
Feature branch (usually multiple): dedicated to a single feature or a bug fix, usually builds, automatic tests usually pass, after completion is reintegrated to the trunk and deleted
Stabilization branch (may be multiple, but usually one): dedicated to a planned release, automatic tests pass, used to generate builds to be sent to QA, internal/external release tags are created from it, some fixes or even features may be merged here from the trunk