Guide And Best Practices For Subversion Branching
Since switching to Subversion for version control about two years ago at work, there have always been questions about best practices here and there which were certainly debatable. One of the last long discussions/e-mail threads we had about Subversion was about when to branch, when to stay on trunk, etc. Ned Batchelder wrote a great introduction to branching which you can check-out here.
Using a branch is always more involved than using the trunk, so the trunk should be used by the majority, and the branch should belong to the minority. Subversion is easier than other source control systems in this regard, but the rule still holds: when trying to decide what goes on the trunk and what goes on the branch, put the code that most developers want on the trunk, and put the minority on the branch.
I think one not-immediately-obvious thing to think about when branching is that none of your incremental changes to the branch will show-up in the trunk revision once you've merged the branch back into trunk. Instead, you only get the revision where the changes were merged back into trunk. Being that we link revisions with tickets and tasks, it presented a difficult problem to track down changes because people were using branches way too often. For the most part, we now follow the basic rule that you should only create new branches while doing some major changes to existing implementations, or interface changes, while most everything else such as maintenance, new features, and bug-fix type items belong in trunk.