Bil Simser has written a great article on the day-to-day use of subversion. It explains everything from the initial set-up, through tagging, branching, and merging.

His example uses a branching pattern called "Feature Branching". Another name for feature branching (and one you might be more familiar with) is "Development Branching".

The idea is, any development work is done in a branch until such time as the work is considered complete and ready to merge back into the trunk. Release builds are done directly from the trunk.

The other major branching pattern is "Release Branching". In this scenario, all development work is done on the trunk. When the current development phase is considered complete, a build is done and tagged, then a branch is made. Any maintenance work is carried out in the branch and subsequent releases can be made from it.

The method used to introduce me to subversion was release branching. I believe it's the method used by Microsoft in operating system development.

I'm pretty comfortable with it, as it's how I've been working for a while now. I think it's the simplest form to work with, but you're putting a lot of faith in the people developing in parallel with you. If they screw up, the trunk is hosed.

Feature branching means a bit more overhead in your development workflow, but the benefit is the trunk is always good. Should someone hose the branch, the trunk can still be built.

If your build is always being broken, try feature branching. If you're a small team with good communication and a lot of trust, use release branching.

If you want an in-depth exploration of software configuration management (of which, revision control is one aspect), have a look at this site.