The other day I was asked this question "When do you Branch? When do you Label?"

On the surface most source control system will look the same when you branch or label by copying the source code at a particular revision number.

Labelling however is really just a "point in time" reference to a revision number, this way if you wish to revert your code to "Release 1.1.2.3a Beta 9 hotfix 6" then you just revert code/go to revision etc and your source is at that point.

If you just did a label and a user submits a bug, then you would revert to this label make the fix and do a compile and deploy, now the tricky bit you need to put your fix back in source control for the next release. Well you would have to go back to the lastest source and apply your changes. Now what happens if you get another fix, then you have to go back to the label and then apply BOTH changes as the fix was only ever commited at the latest source and becomes a headache on what was fixed or changed, now throw into the mix another 5 developers and each one working on a fix themselves.

This is where Branching comes in to allow you to make changes on a particular version, my recommendation is that whenever you do a "Release" to the User Acceptance Testing system that you do a Branch. This way you can continue on your merry way with the development team making changes in the trunk.

When a user picks up a bug either in the test system or from a release you can immediately switch to this Branch make the fix, compile and deploy a version with just that fix, then merge your changes down into your trunk code base. When doing a Branch I would recommend Labelling the trunk at that point in time as well just so you know what revisions have been done since the last release for a changeset document. This way when you need to go back to Release 1.1 you have all fixes that have been applied over time and can keep on adding fixes and then merging back to the trunk.

Why wouldn't you just update the trunk with the fix then do a release? Well if this bug is reported 2 weeks after the release you may be right in the middle of a build cycle (well actually at the end of it if you follow a more agile approach with smaller iterations) and you would have to do a release with a whole bunch of features that the users would have to test just to fix 1 production problem.

With the ability to switch between branches and merge changes between your branches and trunk all the more easier it makes for a quick turn around of fixes and can save a lot of grief trying to get a fix into production.

Figure: By merging changes from the Release Branches back to the trunk you can do a Release anytime off the trunk and have the latest fixes no matter what release was updated.

Coding horror has a great article on different ways of branching http://www.codinghorror.com/blog/archives/000968.html