Source Control Best Practices (Part 1 of 2)

Source control is source control. Whether you use PVCS, StarTeam, SVN, ClearCase, SourceSafe, or Team Foundation, the fundamentals of checking in/checking out and
branching are the same. Most Source Control tools support branching in one way or another, and if they don't, you can do branching manually if you have to.

The first rule of branching is that you shouldn't branch if you don't need to.
Branching introduces complexity and overhead into your development environment, which is something to be avoided whenever possible. A rule of thumb for this would be: if you don't have a version of your software in production, you don't need to branch, (yet).

The purpose of branching is to allow you to fix production problems in the final released source while allowing new development to continue unimpeded.

For example....
I am on a team that is building a new CRM system. We put version 1.0 into production over the weekend, and, on Monday, we make some major overhauls to the security module. Several changes are checked into the main branch, but are not fully tested. On Wednesday, we find a security hole in the production version of the security module. Rather than fixing this on the main branch which has several
untested changes already checked in, we would get the code from the
production branch that we created over the weekend, patch, re-test,
deploy, and check these changes back into the branch.

After checking back in, we look at the differences between the production branch and
the main, development branch we are using and apply the same change we
just made in production to the development version.

Because you only need to patch and re-test a specific production
issue, you are able to isolate the change and thoroughly test and
release a specific change into production with confidence. This technique also allows you to move forward on new development initiatives with
confidence without worrying about how difficult it may be to roll-back
a change if you need to get back to the production version.

These concepts are not overly difficult or complex, but it is important to understand the correct way to branch, using the process and intent that source control allows.

If you do it correctly, it's easy and you will run a clean, efficient shop.
If you do it incorrectly, you will waste valuable time, effort and lose the good will and morale of your development team. Nothing is more
frustrating than working on a project where source control procedures
are erroneously applied. (I will write more on this subject in my next post).