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:
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.
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!