I’ve used a large number of source control systems over the years; SCCS, SourceSafe, ClearCase, P4, TFS and probably a couple others I’m forgetting. Today’s crop of tools include svn (although it seems like that one’s on the way down) and git. I’ve done some investigation into them and have reached a conclusion:
I’m bored with source control tools.
The tools are the least important part of sound source control practices. The tools are almost all the same in raw capability, and have been for many years now.
There are two, and only two, important precepts to achieve source control nirvana. I shall reveal them at this time:
- Use source code control.
- Use as few branches as possible.
Experience a great sense of inner peace…
The biggest and worst mistake is to not use source control. I was lucky — my first out-of-college experience included version control. Back in the day it was performed by a guy on the team rather than a tool, but the tool came along presently and the guy moved on to more fulfilling work. I’m still shocked when I hear that this basic staple of software engineering is not practiced! I can forgive students, and even hobbiest projects, but any commercial endeavor that isn’t using source control (and I include “creating backups” as part of source control) is being irresponsible.
But the second biggest mistake is actually quite widespread, and shows no signs of imminent demise: using too many branches. Being able to create a branch and manage its contents and merge from branch to branch is an essential capability, especially for release management purposes. So “hurrah” to the tools for enabling it. But it isn’t, in and of itself, a Good Thing.
Merging divergent branches is painful, time-consuming, tedious, and error-prone. No one wants to do it, even when the tool support is good. Merging branches that have not diverged is easy, but in that case there really wasn’t a need for a branch.
So set up your development and release processes to avoid the need for divergent branches as much as possible. Use branches when stabilizing for a release, but make sure those branches are not long-lived and that check-ins on them are limited. You don’t need a branch for a day’s work — just check it in on the main branch and don’t mess about with branching, rebasing, and merging. You don’t need a branch for a new feature — just disable it through a switch in the application or the code so that there is no risk of it affecting other features until it is enabled.
Don’t rely on a source control tool to solve all your logistic problems. Take control of your source by taking control of your processes.