Ivan’s agile thinkings

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.