Generally speaking, workflow is usually customized for specific team / project.
I worked with the following workflow:
Trunk is a place for main product trends. It contains currently developed version or product.
Branches are created for all released versions of a product. Hotfixes and minor updates are done in branches (and then built, tested and delivered to end-users). Similar fixes are committed to trunk, as well (or merged from branch altogether later).
Sometimes separate branches are created for big features, when feature development is done by group of developers, and/or may significantly affect other developers. Advantage of this approach is questionable, and depends on specific situation, because merge procedure in SVN is sometimes expensive.
Developer's machine keeps only working copy, with version developer is currently working on. Developer makes updates frequently, and fixes all conflicts. Also, developer makes commits with ready-to-use code frequently.
Product is built and tested frequently - this allows to find newly introduced bugs as soon as possible.
Merge procedure is rather expensive in SVN. Further workflow complication may result in painful merging. BTW, some teams cope with this successfully.
I'd recommend to take a look at distributed version control systems, as well. This post by Joel Spolsky provides great description of their main advantages: http://www.joelonsoftware.com/items/2010/03/17.html
Answering to your particular question, I may suggest the following (BTW, I can't see the whole development procedure, so this may be non-applicable):
Active development is performed in trunk. Trunk version is installed on test servers.
When product is accepted for release, new branch is created. This version is installed on production server.
Further product development is made in trunk, as well.
Hotfixes are made in corresponding branch. Branch version is tested on test servers and then delivered to production.