Going subversive

10 September 2012
When I started at my current company, I adopted Mercurial as my version control system. Although great for software development, it is not an easy system to get into. Distributed version control is already a big leap for people who understand centralised version control, so people who are complete virgins are in no-hope territory. This weighed on my mind when I had to decide what system to leave my company with, and I opted to go back to Subversion. This was for two fundamental reasons:
Revision numbers are king
The choice of revision control has to be in context of what the prevaeling alternative is, and currently this is the make-copy-of-entire-folder approach. Any system with a fighting chance has to be one where you can say Revision X, and there is no doubt whatsoever which set of files this refers to. These revision numbers also have to be human-friendly, and opaque changeset hash values don't cut it.
The real killer comes when setting up an automated build system that embedded version information into program binaries. A 3-4 digit decimal revision number is nice, but a 12-16 digit hexadecimal changeset hash is not something you want to try and get a customer to read out over the phone. Given two arbitrary revision numbers and you at the least know which one is newer and could hazard a guess of their relative ages, but changeset hash values are meaningless.
Rigid centralisation essential
While it is possible to have 'central' repositories with Git and Mercurial, it is not an inherant part of the work-flow of distributed revision control. In fact the whole idea of distributed revision control is to avoid them. This is bad when the central repository not only has to be unquestioned, it has to be unquestionable.
To a boss who just wants a complete snapshot, anything that could deviate from having a single repository is regarded as little more than a second layer of complexity, and you are back to stage one. In fact since repository data-files and working copy files are kept in-situ, there is the significant risk of someone by-passing the propert mechanisms accidentally trashing something.
My clear intention is to leave behind a good build-control system, because longer-term it is the process of going gold where i foresee the company having problems after my departure. Subversion's role is in pulling all the components into a central place, and the emphasis is on then using revision numbers as de-facto build numbers, so in this sense Subversion as a development aid is very much a secondary concern. This is why I went back to a notionally more primitive system.