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 Pablo Santos 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.

4 comments:

  1. when will you go online?

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

    Ian C.

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

    ReplyDelete
    Replies
    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?!

      Delete