Subversion Change Sets
Tuesday, February 19th, 2008For 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.