Who we are

We are the developers of Plastic SCM, a full version control stack (not a Git variant). We work on the strongest branching and merging you can find, and a core that doesn't cringe with huge binaries and repos. We also develop the GUIs, mergetools and everything needed to give you the full version control stack.

If you want to give it a try, download it from here.

We also code SemanticMerge, and the gmaster Git client.

4 steps to make version control shine

Thursday, August 07, 2008 4 Comments

In the beginning everything was flat.

Now, fortunately, it isn’t.

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!


  1. The technical paper on which Mark's talk was based is available here: http://people.ubuntu.com/~ianc/papers/community-agile/.

    Ian C.

  2. If each feature is branch where do tester test the changes, does that mean for every branch we need new project deployed

    1. I would also like to know your opinion on this, this sounds great but ideally the testers should be able to alpha test before you integrate to the mainline, where can they test it? you can't have an environment for each branch surely that'd be too much?!