OSS Watch team blog

For some years the OSS Watch team has been using Subversion. In fact, OSS Watch was the first team outside the Systems Development team (commonly called Sysdev here) to migrate to Subversion at Oxford University Computing Services (OUCS). No need to go into the reasons why OUCS switched to Subversion for version control since I’ve detailed those elsewhere. However, it is worth pointing out that OUCS was already using version control across a large set of websites, including OSS Watch’s, prior to the switch to Subversion in 2003. The change was therefore merely one in the minutia of working practices rather than philosophy. Most sites at OUCS used, and continue to use, a distinction between preview and publish. Preview is the internal or possibly development version of the site, and Publish is the live version of the site.

In those early days we were simply using the version control system supported by our host institution. And since we were so small and focused more on awareness raising than practical software development support, the way we used subversion was not that important to us.

Latterly OSS Watch’s focus has changed. In the past year we have grown significantly and now offer a substantive practical consultation opportunity for JISC-funded software development projects. As our attention turned to the practicalities of software development environments, especially open source development environments, we naturally began to reflect on our use of Subversion. Did our use of Subversion represent best practice? No. In fact, due to the way we had used Subversion over the first three years, there was no history preserved between preview and publish. There was also no easy way to simply change our working practices to use more standard Subversion commands such as svn merge or svn copy.

Of course most members of the team were perfectly capable of using Subversion differently in any software development project in which they might happened to be involved. Just how you use Subversion correctly is best explained in the freely available book (and Creative Commons licensed) Version Control with Subversion. Our questions instead were: Could we use Subversion this way within OSS Watch itself? What would justify the change-cost? And who would manage the process?

OSS Watch is nothing if not a learning team. So we sat down at one of our monthly full-day team meetings and thrashed out all the issues. Could we move from our current preview / publish set-up to the more traditional trunk, branch, tag set-up outlined in the svn-book (above)? Yes, but at some cost. After discussion with Sysdev, we concluded that the only way to make the move was effectively to start again from scratch and set it up right this time.

In the proposed new arrangement, trunk would become the new preview. Our new publish would be a branch, suitably named branch/publish. There were also a host of legacy issues with how we had been using the old preview - essentially it had become a dumping ground for content we wanted to share across the team but had no intention of putting on the website. That’s another challenge which we have safely shunted to another day by moving the old preview into branches/legacy.

So, we had a possible plan, but what would the positive benefits be that would justify this effort? I think the benefits boil down to two:

• re-enforcing best practice in Subversion use across the OSS Watch team
• beginning to use Subversion as a communications tool

Since we use our version control system every single day, the first benefit would be quickly realised. Our knowledge of using Subversion in much the way the svn-book recommends would become second nature. That would put every member of the team in a better position to help a JISC-funded software development project that might be wanting to use Subversion and needing some guidance. It also supports continuing professional development (CPD) for team members. It would be somewhat embarrassing to go off to a new job after having used Subversion for years while working for OSS Watch only to discover that you had never really got to grips with the fundamentals of Subversion use.

The communications point is not something that is exploited by all those who use Subversion. However, it is used as a communications tool in many software development projects. By arranging for Subversion to send a ‘commit’ email to a mailing list each time someone commits a change to a file, you can very quickly build up the ‘commit then review’ work practice. Of course we already had that practice within OSS Watch in that we would often send an email to the rest of team when we had made a substantial change to a document on the site and were looking for internal feedback. But now we could automate this. For example, this is how the Apache Forrest project uses Subversion. I have certainly found that such a use of Subversion aids participation for newcomers who can more easily see changes as they are being made. It’s a good practice that can, in software development projects, also aid the development of community. For OSS Watch it would serve to reduce the number of steps that previously had been involved in the commit then review process. But it would also serve the double purpose of supplementing our working knowledge of how best to use Subversion for community building in software development projects.

For us, the above was sufficient to warrant the change-cost. The final question was simply who was going to to manage the change? I’ve already hinted that this was a team decision. The practical steps - working up our migration plan, liaising with Sysdev, testing, support - were put in the hands of Ross Gardler and Stuart Yeates. Ross and Stuart are probably our most experienced Subversion users, at least with respect to software development projects. The migration project itself also served as an excellent opportunity for Stuart and Ross to work together on a tight, time-limited, core mini-project. So, once again, good for the team.

I’m delighted to report that the migration has gone well. The whole team is now working with the new set-up, ably supported by Ross and Stuart. I think it already qualifies as a success.

Is that the end of it? No. But it does lay the foundation for what we will try next. Soon we will start using tags to correctly indicate versions of a document that make it into support packs distributed to projects at OSS Watch events (call them releases if you like). There are even more steps planned, but slow and steady will get us there.

So why a blog post about this? Because I wanted to provide an insight into how OSS Watch grows as a team, learns new things, revises its work practices, and succeeds together. Maybe that’s something we can share with other JISC projects as well