Ivan’s agile thinkings

Last weekend I wasn’t feeling so good due to a bit of a cold.  As I manage more than I do these days I don’t often get time to code.  Interestingly I’ve noticed a bit of a trend that I code more when I’m feeling ill.  I don’t really understand it, but as long as my brain is working and my body doesn’t feel like doing much I suppose it’s nothing to worry about.

On to the main point of this post.  My company is currently using Subversion as its source control mechanism. I’m pretty sure I want to change this to something better.  I have the influence and power to be able to enact this change, potentially overnight if I REALLY wanted, but that would be as successful as flying to the moon in a sherbet-powered watermelon.

For a start, I’m not 100% sure of what ‘better’ would be.  We’ve had a small grass-roots movement trying different types of DCVS for a while.  Basically this meant Mercurial and Git.  Git seems to be winning out at the moment, and its got to be said that the git-svn seems very solid.

I’ve been tracking svn using git-svn for a while – I might not ‘do’ so much any more, but I know the answers to lots of things and need the code to refer to.  But last weekend was the first time I’ve used Git in anger.  So, I set about tidying and refactoring a set of unit tests that are horribly coupled to a large chunk of the system – and are slow because of it.

What a difference Git made to my work-flow!  Edit, compile, re-run tests, COMMIT, edit, compile, re-run tests, COMMIT.  I was committing many, many times more than I ever would have with Subversion.  Even if I had my own Subversion branch to isolate my changes, the time to commit over the network would have stopped me doing it so often.  Git was a breath of fresh air.  Knowing I could just do my work and commit as part of my workflow was very liberating, confidence giving and really quite enjoyable.  At the end of the session, I simply ran ‘git svn rebase’ re-ran my tests and ‘dcommit’ed back to Subversion.*

I have a longer term plan to get a GitHub style development system internally at work and this experience has encouraged me tremendously.  So much so that this long-weekend I installed gitorious and gerrit on a VirtualBox VM to give them a test drive.

Anyone else changed from Subversion to Git?  Got any pointers or war stories?

* Actually I got a little help from a colleague to move my changes onto a git branch so then I could merge/squash them before committing. Thanks for the help and learning Mehran.

I’ve rarely had to use a commit token.  The teams I’ve worked in generally edit unrelated source items as much as is possible.  Over the years I’ve read about various amusing items being used as commit tokens: rubber ducks, action figures, hats and little flags, to name a few.  The general idea is that you should physically have the token to be allowed to commit – meaning there are no updates made to the source repository so your changes will go in cleanly.

It is possible that this could be side-stepped though – Mr Naughty Committer might pretend to be holding the Pokémon and commit – how can the source repository be expected to know where Pikachu is at any given moment??

However, one of my colleagues had a great idea the other day – ‘The Ultimate Commit Token”.  Simply appropriate one of those single use password setups with a single key fob.  You could try borrowing it from your corporate VPN setup – I’m sure they wouldn’t miss it.

Wire your pre-commit script into the server-side element and have the fob floating between developers.  Et Voila! One very annoying, yet extremely effective commit token!!!

I know, I know, it’s not very exotic looking, but fear not!  I reckon it would look natty glued to the back of Spud Of Nine.

For some time now I have been looking around for change sets in Subversion, the ability to group files together connect them to issues and commit and track them as sensibly labelled groups with the ability to merge these groups between branches without having to specify individual files.

Many years ago when working for a telecommunications company in the UK I had the pleasure of using ClearCase and more importantly ClearQuest. I seem to remember being able to see the files I was changing for any specific issue at a glance. My job as a build engineer was also made much simpler being able to working with the change set abstraction doing just as I describe above when it came to merging. So scouting around the interweb I went.

The first interesting thing I hit upon was clearvision’s ClearQuest Subversion Integration this seemed a bit like what I was looking for and not too badly priced, except where I work now doesn’t use ClearQuest and isn’t about to. On my search went.

I eventually found this page on Auke Jilderda’s blog which detailed some of the changes coming in Subversion 1.5 to arrive late summer.

Subversion’s upcoming 1.5 release is scheduled to deliver the core merge tracking feature with subsequent releases likely extending this. Fundamental to all merge tracking related functionality is the functionality to automatically record what change sets have been copied, or merged, where. On top of this, the 1.5 release will deliver the following functionality:

• Repeated Merge

• Cherry Picking

• Record Manual Merge

• Rollback Merge

• Block/Unblock Change Set

• Automated Merge

That sounds pretty much exactly what I was looking for – and then some

The first comment on Auke’s post then led me to the SVK project which also seemed to offer a lot of these types of feature already (as the comment mentions). I agree with the later response that Subversion could do with these features in its core, rather than in a specific client, particularly as we don’t currently use that client and we use Eclipse a lot. SVK is interesting to me for another reason though, its similarity with git. From the little I understand about git it provides a very different way of thinking about version control which obviously fits the Linux developers quite well. I recently read something about git and the way it provides a decentralised approach to version control, and providing a new style of file system at the same time.

Along with the Mylyn Eclipse plugin and a few other things I’ve seen there’s a lot of fun things going on the configuration management space at the moment. I’ll be keeping my eyes peeled and hoping core Subversion change sets arrive early.