I think the best first step is to match up Subversion's nomenclature and concepts with your own, otherwise I think you'll tie yourself in knots. For instance "switch the trunk to the branch" doesn't make sense. I suspect what you mean here is actually: "switch my working copy that currently contains the code for the trunk so that it contains code for the branch instead".
The repository stores the current state of the trunk and of any branches that have been created. Typically you would create a branch when you want to go back to fix bugs in an earlier release (eg for a 1.0.1 release) while you've made more substantial changes on the trunk for version 2.0 that would be too risky to put in 1.0.1.
When you work on a project you check out a working copy from either the trunk or a branch. Any commits you make will end up on the trunk or the branch you've checked out. If you need to work on the 1.0.1 branch you have two choices:
- Check out a new working copy for this branch. Any commits get pushed onto that branch
- Switch the working copy that you were using for the trunk so that it now follows the branch rather than the trunk. Any commits now get pushed onto the correct branch.
Which one of these two approaches you take will depend on a number of factors:
- Do you have changes in the working copy that you haven't yet committed. If so then the simplest thing is to check out a new working copy. If you want to switch then you risk losing them, so either commit then or create a patch and put it aside
- Is it expensive to create a new working copy? eg it might be a very slow network, a huge source tree, or take many hours to build. If so then you might prefer switching
- Do your projects rely on hardcoded paths? If your build scripts assume that everything is in
c:\source
then that means that you can only have one working copy and you'll have to use switching.
For simplicity though I would recommend creating a new working copy for the branch.