I found this great article by Bill Simser on Day-to-day with Subversion where he explains practical use of Subversion branches, tags and merges. As a additional reading it might help if you read the documentation on branching and merging from the SVN Book from here but Bill's explanations made me understand better. And allow me to share my notes on this. [more]
I haven't had much experience on branching/merging with SVN yet but in the scenario presented in the article where you create a branch when you need to work on new features but maintain fixes on the currently deployed version in production what I've known is that the developer would work on the new features locally while the rest of the team works on main codebase (trunk). That poor developer will not check in any changes he/she made to the repository until he/she has it done.
From time to time the developer should retrieve/merge changes made to the trunk (to his/her working copy) to make sure that he/she gets the changes in increments rather than a whole bunch of merges when he/she finally checks in the code. This daily merge is applicable in both Bill's suggested approach and the one I've known (let's call it "no check ins until feature is done").
The disadvantage with "no check ins until feature is done" is that the poor developer looses any version control capability on his/her daily changes or worst since no check ins are made to the repository, once the local machine crashes, all those days/weeks of new features changes are bye bye.
So branching and merging may seem a little complicated than simply maintaining a trunk and doing all changes there and for any new feature no changes will be checked in until all changes to accomodate the feature is stable and integrated succesfully. But the former will enable the poor developer working on the new feature to version his/her own changes in his/her own small new features world and prevent the risk of loosing it bigtime.
Another common scenario when maintaining a trunk but poor developer still wants to check in small changes for the new feature from time to time is to comment out the new feature code before checking it in. In that way, there is revisions are tracked but doesn't affect the application since they're commented out. But this leaves us with a lot of commented out code not being used or as mentioned in the article, a ghost button where if clicked doesn't do anything or a cardinal rule which says "don't click this button, it's there but it's not implemented yet".
Warning though, branching and merging should not be abused too and would take some skill/experience to determine when to branch versus making the new version changes on the trunk directly. Out if my head I could think of simple refactoring and bug fixes should be made to the trunk but new major revisions such as migrating from .NET 1.1 to .NET 3.5 or architectural changes should go with branching/merging.
FInally, note that regardless of your approach to branching and merging vs.
making all changes to trunk, tagging on the other hand is another story
and must always be used when labelling/cutting versions.