4 steps to make version control shine

4 steps to make version control shine

Thursday, August 07, 2008 Pablo Santos scm 4 Comments

In the beginning everything was flat.

Now, fortunately, it isn’t.

Background
Ok, why I’m writing this? Well, this week I had the chance to take a look at two great presentations from the OSCON 2008:

The first is from Mark Shuttleworth (Canonical, Ubuntu), titled Beyond Agile: Enabling the Next Wave of Software Development Methods, and talks about a number of very interesting topics such as Lean Software Development. You can find the slides here.

What I really liked was slide 17 where he says:

Branching and Merging
  Keep trunk pristine,
    Keep features flowing,
      Release on demand.

And slide 20 where he mentions:

Pre-Commit Testing
  I see you knocking
    but you can't come in.

I also liked Code Reviews for Fun and Profit, from Alex Martelli (Google) which you can find here .

He mentions the following on slide 26:

ideally, CR mailing should happen BEFORE
actual commit/push of change-set to the
codebase -- upholds trunk/head/tip quality

Which also does look interesting, right?

So, I came up with this post.

The rules

Let’s try to find which ones are the key rules to make version control shine in the post-agile era:

Rule 1: Keep your main branch (trunk) pristine. Your main branch is your project! Don't use it as a garage (full of garbage) to park all the fixes and new features. Use branches instead!

Rule 2: Isolate changes in branches. It is a consequence of Rule #1. Place each bugfix and new feature inside its own branch. It will help keeping the main line clean, and it gives you all the power of real parallel development. It's also great for task switching and keeping track of intermediate changes.

Tip: Associate your branch with a task in your issue tracking system (Bugzilla, Mantis, Jira ...) and close the full cycle.


Rule 3: Commit often, more often than you do now! If you develop on the main branch you won't commit every 5 minutes, changes often take longer! If you have your own branch for the task, you're free to commit as many times as you want to... and then you get private change history.

Rule 4: Review changes before they go to the mainline. In main branch development (and continuous integration) you run the test suite after the changes are merged. Don't! This is too late, code is already broken! Take the best out of your SCM tool, review your changes before integrating!



The good news is: there are tools supporting this model both on the commercial and the open source worlds: plastic, accurev, git (bazaar?)...

The bad news is some of the most extended tools out there can’t.

A new era is coming... get ready!

Pablo Santos

I'm the CTO and Founder at Códice.
I've been leading Plastic SCM since 2005. My passion is helping teams work better through version control.
I had the opportunity to see teams from many different industries at work while I helped them improving their version control practices.
I really enjoy teaching (I've been a University professor for 6+ years) and sharing my experience in talks and articles.
And I love simple code. You can reach me at @psluaces.