Versions of version control

Earlier this month, the developers at Manchester released a new version of the NGS accounting clients - with Condor and limited support for Sun Oracle Grid Engine.

Those readers who stumbled across the earlier R+D posting `Who, where and how much?' may recall that the accounting clients translate the records from local batch management systems into a format suitable for accounting on a Grid.

The code - like other software developed within the NGS - is being distributed via the NGS project at NeSCForge.

NeSCForge is a version of the GForge Collaboration Toolkit hosted at the National eScience Centre. In addition to using it to releasing packages, we also make some use of the revision control service.

A revision control service allows all changes to the files making up a package are recorded in a repository - with associated log messages - allowing the history of a piece of software to be tracked. When bugs bite, the ability to identify when a change was made is invaluable.

The revision control service is based around the venerable Concurrent Version System
(CVS). When CVS development started, back in 1993 according to CVS's own ChangeLog, CVS was the bees-knees if you needed to keeping track of large numbers of files.

The bees-knees aren't what they used to be. Many developers have moved on from CVS to Subversion or to distributed revision control systems like GIT. We use Subversion at Leeds, my colleagues at Manchester prefer GIT.

Some NGS software development, such as that for the VDT installer , is done via the NeSCForge CVS service. A lot is done via private repositories and other revision control software.

When code is developed in private, people outside lose the ability to spot when and where the bugs appeared. If you are developing security-sensitive software which can be used by anyone, it could be considered good manners publish these in a public repository.

If you use NeSCForge for that public repository, you need to feed everything to CVS.

This is easier than it sounds...

GIT comes with a git-cvsexportcommit command - that will translate GIT changes into CVS-ish commits. Subversion users can download and install svn2cvs.

We use svn2cvs at Leeds to mirror changes to X509runsetgid - mentioned in last week's 'Licensed to Grid' posting - to NeSCForge. For this to work, you need to give NeSCForge a SSH authorized key and use somewhat verbose command line...

env CVS_RSH=ssh svn2cvs.pl \
$SVNROOT/x509-setgid/trunk \
:ext:developerid@forge.nesc.ac.uk:/cvsroot/ngs x509runsetgid

While it can be a little embarrassing to leave a record of every bug you created in the public domain - you can console yourself with the knowledge that you are doing other developers a favour. While it is good to learn from your own mistakes - it is much better to learn from somebody else's.