Quarter Life Crisis
The world according to Sven-S. Porst
« Black • Main • Bratze Live »
Versioning Systems¶
2209 words on Software
The point I’m trying to make is that versioning systems are a good idea but that a lot of that gets buried in geek hipsterism. With all the hip versioning systems around these days, the effort of using them may just be bigger than the convenience they provide.
Where I’m coming from
Versioning systems like the classical CVS or the rather commonplace Subversion are interesting tools for software development. They let you keep track of the changes made to code and thus simplify things like change tracking or collaboration on the same files. They seem to be a sine qua non of communal programming efforts but can also be quite helpful when working on your own.
As these systems come from the developer / geek side of the universe, they are usually non-obvious to use which makes them rather unattractive to the casual user who may only use them occasionally. As always, using a model of ‘read a bunch of manpages and find the relevant two lines in a hundred page book’ rather than one of ‘instant gratification’ is a great way to turn people who might totally appreciate the power of that software into non-users. Chacun à son goût.
The key to making versioning systems accessible is putting a reasonably pretty face on them. A first attempt to do that on the Mac may have come from Apple’s XCode IDE which has offered direct integration with (the now passé CVS) for a long time. And it supported Subversion for a while - even though you had to manually install the Subversion binaries before the developer tools that shipped with X.5.
My first run into versioning system was when I was helping out with BibDesk a few years back. While the first checkout (and even checkin!) seemed scary, it was OK to use through a GUI and the advantages of collecting the effort of many people along with comments on their work seemed obvious soon. I started liking versioning systems back then, simply because they seem to be the obsessive-compulsives’ way of filing their work. Certainly beats a simple ⌘S.
When working on Sandvox Designs with Karelia it unfortunately took us quite a while to figure out that using Subversion for that is the way to go as well. After losing some data over time because the whole zip-upload-unzip-figure out what changed process we had wasn’t the most efficient or controlled one, we switched to using Subversion and never looked back. Not only did this prevent files from going the wrong way by accident, it also established a clear history of what went on when and who’s responsible for it. All that with everybody involved being able to get the relevant information right when they need it (rather than when the person in charge on the other side of the world is awake).
2008
So there I was, kind-of liking Subversion and even starting to use it occasionally for my own local projects as a sort of pimped backup. But generally it still wasn’t all that nice. Because I kept finding the command line interface clumsy, XCode the wrong application for some of my projects and early Mac Subversion GUIs like svnX honourable efforts on the ugly side.
Strangely all that changed in 2008. For some reason the subject of versioning systems - in particular Subversion - became a big one this year. And not only did Coda gain Subversion support in version 1.5 but we also saw the release of Cornerstone and Versions, two polished dedicated graphical Subversion clients. Bliss.
In case you care: My verdict on these is that Coda’s Subversion support is a nice try but mostly useless (in particular as I cannot submit files unless I opened the ‘Site’ belonging to its repository first) while Versions and Cornerstone both seemed fit for the task. I quite liked Cornerstone’s own presentation of Diffs but found its user interface counter-intuitive in most places. While Versions’ GUI rang the right bells for me. There’s still a range of improvement possible in Versions but it’s getting the (little) stuff I need done; In a pleasant way. [And, yeah, I always end up liking the application with the green icon better…]
Problems
This doesn’t mean that versioning systems are without problems now. It’s just that the client side improved significantly. And such significant improvement may mean that you start being inclined to use them more frequently. But other parts of the ‘ecosystem’ haven’t quite caught up. In particular they seem to try hard to remain as user hostile as possible.
And I don’t mean that necessarily as a Subversion specific issue but more as a cultural one. The whole industry of publicly hosted source code lives from the illusion of ‘open source’ software. Anybody can read and use the source code in question. If the projects’ maintainers like him, he can even return his changes to the project. If they don’t there’s still the mysterious process of ‘forking’. Whose main purpose seems to be creating a royal mess (the Cathedral is nice and orderly and has a waterproof roof at least…).
However to me this ‘open’ attitude never came over as a particularly sincere one. My idea of ‘open’ software would be software with readable source code and - if needed - documentation to get it running. My idea of open software also includes single click red-tape-free downloads for people who don’t have or can’t be bothered with versioning systems (even if Subversion became magically more accessible for me this year).
The current situation seems to be far away from my idea. Public hosting sites (Sourceforge, Google Code, beanstalk, …) seem to invariably not focus on these very basic aspects. They may offer bunches of cool (in someone’s opinion, anyway) tools, gazillions of links, statistics, wikis, incomprehensible bug trackers and whatnot. But apparently a readymade link for a single click download of the current source code seems out of question.
Which is unfortunate.
It’s unfortunate because many people may only have a casual interest in programming. Or they may just be curious to know how a certain thing works. And making such simple steps difficult will kill rather than nourish that curiosity. Just as everywhere else there will be many more people watching than people actually creating things. Yet the user interfaces seem to be made exclusively for the minority who use the systems very actively. (And I’m tempted to argue that it’s not even brilliant for them.)
The future is worse
I think this motto of making things easily accessible is an important one. While I am totally not familiar with the intrinsics of Subversion (apart from it having the obvious design flaw that you’ll end up in hell if you dare to do something as outlandish as deleting a folder in a working copy), I am more than tempted to believe that they aren’t technically brilliant in all possible ways. And that there may be better ways to do the same thing - or even more.
And every day a geek seems to get up and have the same thought. A bit later they’ll have created their own brilliant versioning system, and they’ll have found an utterly clever name with a nice and short acronym for it. If they have sufficiently many friends, their system may even make it to a wider ‘public’ and we end up with things like git, bazaar or mercurial with its smartass command name.
Giving them the benefit of the doubt that they actually do things better than Subversion the issue here is that where we initially had a single (or two if you still consider CVS) problem, we now have three new ones. Because somehow, while living out these wet dreams, the geeks forgot to make their fantastic new systems backwards compatible. Which means that you’ll potentially need to download, install, update, and repeatedly read the man pages of a bunch of new tools just to keep track of a bit of source code.
Of course your main objective was getting that code and using it but now you’re stuck dealing with yet a new layer of software that you installed for a single cause. That just seems to be an incredibly bad deal to me. Because most (sane?) people won’t really appreciate installing what effectively is nothing but a new download tool for a single set of files. Most
Illustration
To illustrate this, look at what happened when I programmed Symmetries earlier this year. Symmetries makes use of two public frameworks. One is the SSCrypto framework. It is available via Subversion. And I quickly checked out a copy and adapted it for my needs which mainly meant turning on garbage collection in the build settings. The framework only handles verifying registrations in the application and with one of the first registrations a subtle bug was revealed: it failed to work correctly if a string passed to it had a certain length. After finding this out, I let the developers know about it and it seemed they had found the problem as well and checked in a fix soon after. It only took me a few clicks to update things on my side after this. All that thanks to Subversion being pretty much a ‘standard’ and can be submitted to convenient GUIs.
The other framework I’m using is Sparkle. While not perfect (where’s the option to update on quit?) it remains the killer of auto-updating solutions (who else matches the nice relaunch of the updated version?). However, it is a rather monstrous piece of software. While I thought I could probably just drop most of its code which isn’t used in my application, actually doing that would have required understanding it, which in turn would have ruined the whole time-saving aspect of using a readymade framework. So I limited myself to obvious things: removing the localisations I don’t need removing the 64bit binaries which would be useless, thinning the nib files and, of course, setting things up to run garbage collectedly.
After doing that my version of Sparkle was quite customised. And this brought me into the situation where not having a version control mechanism makes following updates of the project very painful. The problem about following the project through version control software, however, was that it’s using something called Bazaar. And a bit of cursing later I was sitting there with a freshly checked-out copy of the Sparkle source code using yet another tool I didn’t really understand. Of course I didn’t know my way around it and had difficulties finding out how to actually do what I wanted to do. My aim here was simply keeping track of changes in the framework without losing my custom build settings (is that unreasonable?).
Due to Sparkle’s interminable beta phase (still at 1.5b6 now) I think I shipped something 1.5b4-ish. As apparently the required format of the appcast changed after I grabbed that copy I didn’t even dare checking out a newer version as I feared it’d just unnecessarily break things. And as I moved to a new computer since which of course the 3rd party Bazaar software wasn’t migrated to, I didn’t even bother installing it again until I absolutely need it.
Now guess which of these two cases I preferred?
And one could go on and on. Tom’s Flame touch app for browsing Bonjour services from an iPod touch looks cool and I wanted to fiddle with it a litte because I thought it could give a simple way to push an open Safari page from the Mac to the iPod touch. In fact, that fiddling was successful…
I hacked together a little app which advertises the pages you have currently opened in Safari via Bonjour. Flame touch then picks that up and opens the URL in Mobile Safari. You can grab the source code at Google Code. Which is Subversion based but totally sucks as a website as well. There must be better stuff‽
… the caveat being that the project is hosted on the github site, meaning that ‘native’ access to it requires installation of the git tool which quite likely is another piece of software I don’t know how to use and neither care for. All the while Antonio is working on an interesting project based on hg - err, sorry Mercurial which I don’t even want to think about.
My bottom line
The bottom line for me in this is that while versioning systems can be incredibly useful it’s completely unreasonable for everybody and their dog to invent their own new one; Unless they are all compatible to some lowest common denominator standard. At the end of the day the interesting stuff is happening in the code and versioning systems are not part of it. They should provide convenient access to the code rather than getting in the way. If people claim that their code is ‘open’ they should act in that way by making sure it’s easy to access in practice.
In other Words
Think of Subversion as ASCII. The versioning system you just invented will only be a practical improvement if it has a UTF-8 mode which is indistinguishable from Subversion for the basic features.
