Really using Subversion

Posted on by

I have been using Subversion for more than three years. I use it every day. It is the version control system of choice within Oxford University Computing Services (OUCS). But until recently I hadn’t really used Subversion. Or, at least that’s one way of thinking about it.

It is worth a brief digression to consider why we use Subversion within OUCS. I’d like to say it is because we went through a thorough procurement process, arrived at the best possible solution for our needs, and then implemented the action consequent on that conclusion. That’s the ideal. But the dreaming spires of Oxford are just as bound by the contingencies of the real world as anyone else. Prior to switching to Subversion we used Perforce as our version control system. Perforce is an excellent solution – if you can afford the licence fees. I’m not certain of the sequence of events that took place (my role within OUCS doesn’t have me moving in those circles). The upshot was that suddenly we would have needed to pay about 100 thousand pounds if we were to continue using Perforce. Maybe other institutions manage their finances differently, but in Oxford it would take a miracle to change the budget for a sub-unit like Computing Services at short notice. And let’s be honest, 100 thousands pounds was just not going to happen. Not for something invisible like a version control system. So, we needed a solution, we needed it quickly, and, effectively, the solution was not permitted to have any impact on the overall budget.

Do you face these kinds of choices? They are not ideal. But in this case we were lucky. Just at that time a new open source version control system was coming on the scene. For many years CVS had been the standard version control system in the free and open source world. Subversion, an initiative from CollabNet, was being designed from the ground up as the next generation replacement for CVS. Subversion is also an open source project. That solved the cost-to-acquire issue. Its pace of development was substantial, and has continued to be so. And the community of users and developers around it was already large and growing. All that was left was to do some stress testing and then gradually roll it out, one project at a time.

OSS Watch was one of the first groups with OUCS that began using Subversion. Back in those days I had no familiarity with non-Windows operating systems. So I needed to interact with the Subversion repository via a Windows client. Fortunately there is an excellent one, whose development has followed pace with Subversion itself: TortoiseSVN. (TortoiseSVN is released under the GPL licence, whereas Subversion itself is released under an Apache/BSD style licence, even though they both come out of the same development house – a good example of the fact that choice of licence should be on a project by project basis.) TortoiseSVN installs as an extension to Windows Explorer. It takes only a moment or two to install it and barely any longer to learn how to use it (probably even faster if you already have a grasp of what version control systems are meant to be doing).

And since then I’ve used Subversion via a GUI client nearly every day.

But recently I began wondering how open source development projects use Subversion. My guess was that they use it differently than I have been using it. And I was correct.

At OUCS we have greatly simplified our interaction with Subversion. In part that was because we needed to bring along dozens and dozens of staff who were going to find, what I described above as blindingly simple, a challenge. So we went with a simplistic preview/publish distinction and left it at that. We didn’t even insist that publish would need to be a branch or tagset of preview. So there is not necessarily any trail of history between equivalent files in preview and publish. Again, a contingency necessitated by our install base. Probably everyone faces such challenges.

In order to learn how to really use Subversion for code development, I turned to the best source possible – the documentation written by the developers themselves. Version Control with Subversion is an online free publication that details nearly everything that you could possibly want to know about Subversion. I have learned about trunks, branches and tags. I have even discovered just how easy it is to use Subversion directly from a terminal window. It is all very straightforward and immensely logical.

I confess it has been a revelation for me.

In Producing Open Source Software, Karl Fogel claims that developers are unlikely to take your project seriously if it does not use version control with at least minimal competence.

I think he is right.

Mailing list archives

Posted on by

When I begin investigating a new software project, one of the first things I do is explore the archives of the mailing lists. They are treasure-troves of information about the project and its development community. As such, they naturally excite the interest of academics bemused by the open source phenomenon. But my interests are entirely pragmatic.

First, I want to know whether the archives of the list are public. Is this an open project or isn’t it?

Next, I want to see the pace of discussion on the development list. Are there frequent exchanges between the developers? And what is the nature of these exchanges? Do the developers appear to be thinking through the development process on the list itself? Or is this merely a platform for pronouncements? If the latter, then I begin to suspect that the real development list is a private one somewhere else. Again, is this an open project or isn’t it?

How do the people on the development list respond to questions? How do they respond to suggestions? How do they respond to contributions?

My interest is not academic. I want to know how I am likely to be treated in this community. The world is full of open source projects which might value a bit of my time. I want to know whether this is one of them, or whether I should move on.

Of course the list archive is also a narrative history. It has characters who shape the narrative arc. It may be punctuated by events or even conflict. In the best examples, the archive strips away the personalities of the contributors until the code itself becomes the character of interest, undergoing change, facing its own trials.

Software development projects, of course, are not alone in making best advantage of public archives of mailing lists. Take the license-discuss list of the Open Source Initiative, for example. Delving into the archive there can be exhilarating as figures of legend appear, and inevitably appear all too human.

In an age of blogs and Internet Relay Chat (IRC) and podcasts, I suppose that public archives of email mailing lists sounds a bit 20th century. Possibly. But for the foreseeable future they will continue to be a defining feature of open source projects.

Oh, and one other thing.

Everyone remembers the first time they post to a public open source development list. I know I do 🙂

Learning every day

Posted on by

It’s exhilarating, learning something new every day. It’s probably addictive. I know I never want it to stop.

I am not a programmer. Very likely I have little or no facility for learning programming languages. At least not if the evidence of my execrable French and German is anything to go by. Yet there too, I persist. For a number of years I spent every morning between 5:30 and 7:30 attempting to improve my French (yes, I do get up that early – it’s a curse). And still my French is embarrassing to me.

No doubt I would have learned more and learned it more quickly if I could have immersed myself in French language and culture for a week, a month, a year. I could have gone to restaurants, watched television, read newspapers, and most important talked to people. That is, I might have learned more had I lived in French for a time.

I did get the immersion experience in German once. One summer, the first that we were living in the UK, Kathy and I toured what had been East Germany with her uncle and aunt. Neither Klaus nor Erna speak English. Kathy speaks no German. In the parts of Germany that we were visiting there was no intrusion of English – no English-speaking tourists, no English television, no newspapers. So, for two weeks I needed to live in German just to get by, as well as serving as Kathy’s principal translator. Talk about exhausting. And yet, I probably learned more German and better in those two weeks than in the previous four years of modest effort altogether.

Very likely I will never learn a programming language well enough to claim fluency. But the challenge is there before me. And just like learning a natural language, I need to live in it for a time. Fortunately there are plenty of resources ready and waiting.

Python is my first serious programming language (I don’t count the “Hello, World” programs I wrote in GW-BASIC when I was a teenager). Some day maybe I’ll move on to Java or Perl or (shudder) C/C++. I am slowly beginning to grasp the rudiments of the language. I am aided in this by the opportunity to look at, study, modify (if I should wish) and run the source code for a couple of Python-based projects that I follow: Imendio Planner (Gnome Planner, as was) and MoinMoin.

No, I’m not ready yet to contribute any code to these projects. I am under no illusions as to my abilities. But I’m learning to read the code that underpins two applications I use in my daily work. And I’m following the discussions on the development mailing lists for them. Some day, in the not too distant future, I may even start modifying my local copies of the code base. I can at least dream of some day making small code contributions to the projects.

Meanwhile, I’m learning something new every day. I hope I live to be a hundred and one.

ReportTool launched

Posted on by

ReportTool is a simple web application for creating, editing and viewing reports on students’ work. It was created by Stephen Butterfill, a philosophy lecturer at the University of Warwick.

In classic hacker fashion, Steve had an itch that needed scratching. Like faculty in every university department, the faculty in his department had to create, track and distribute reports on students’ progress. From Steve’s point of view, it is much easier to do this on the web than on paper. Since he couldn’t find a free and open source web application to meet his need, he set about building one of his own.

Along the way Steve needed to learn java and web programming. When you’ve got an itch, I guess, you do whatever it takes to scratch it. And, since he is one of the brightest guys I’ve ever met, it wasn’t long before he had a working application.

First make something that works. Then make it better.

Having built an application that is adequate for his own needs, Steve started thinking about sharing it with others. Anyone building an application like this is almost certain to be using so many free and open source development tools that open source just seems like the natural way to go. But how to go about it?

That’s when I got involved with ReportTool.

I have been helping Steve set up a project site for ReportTool. Our modest goal is to gather input from potential users, those willing to try out the live demo, or indeed those brave enough to download the prototype. Future development of ReportTool – including discussions towards which open source licence would be most appropriate for it – will take place out in the open on the ReportTool development mailing list.

It’s been fun working with Steve. And fun setting up the ReportTool site. But I suspect that the real fun is only just beginning…

Being open

Posted on by

How open is your project? It’s a question that should be asked of any open source software development project. It goes without saying that the software being distributed in such a project has an open source licence. That ensures that the software itself is open. What about the project? What about the way the code gets developed?

Sometimes I tell people that the licence is the thing. Without an open source licence, it’s just not open source software. And that’s true. But it’s not enough.

Pia Waugh made just this point to me when I met up with her last week. Amongst a million other things she does, Pia also works for ASK-OSS, the Australian equivalent of OSS Watch. She argues that without open communities, open content, and open standards, open source software is stunted. More and more I begin to see her point.

Yet being open is hard sometimes.

It takes practice. Moreover it admits of degrees and may need to be approached one step at a time. A good start is to set up an open development discussion list. But if you do, treat it with respect. Once you’ve got such a list, then all development communication needs to take place on it.

Either the project is open and this open development discussion list reflects that, or its openness is a sham.