Subversion Causes Brain Damage (according to Joel Spolsky)
I just read part of a Mercurial tutorial by Joel Spolsky and I’ve been thinking about it since I read it. Some people just don’t get it. In this case Spolsky doesn’t seem to get what Subversion is for. He makes the claim that people who use Subversion are “Brain-damaged” for the following reason:
Subversion team members often go days or weeks without checking anything in. In Subversion teams, newbies are terrified of checking any code in, for fear of breaking the build, or pissing off Mike, the senior developer, or whatever. Mike once got so angry about a checkin that broke the build that he stormed into an intern’s cubicle and swept off all the contents of his desk and shouted, “This is your last day!” (It wasn’t, but the poor intern practically wet his pants.)
Okay, so his point is made, but the problem is that he and these people obviously haven’t read The Subversion Book. What he’s describing is people checking in code that they haven’t tested, which is really stupid. What the book says to do is always test before you commit, and if you’re trying something radical make a private branch (which is bloody easy with Subversion), and do your experimenting. Then you merge that branch into a working copy of the trunk, test the changes, and commit if it works. The book generally encourages boldness in the name of collaboration; they certainly discourage the despotic “lead developer Mike” depicted above. If you find out someone’s committed a bug, the mature thing to do is revert the change, then go to the person (or send him an email) and say “Please test before committing.”
I’ll admit that I’ve not worked at the same level of collaboration as Mr. Spolsky, but I have read the (friendly) manual. Version control is all about the ability to track changes, make branches, and do thorough testing. And most of all it’s about the ability to maintain the entire history of your project so you can undo big mistakes. I’ll also say that my attempts so far to demonstrate Subversion to people have resulted in people simply not getting it. However, what they didn’t get was version control, not centralized version control. The situation would have been no different if I’d shown them Mercurial.
Furthermore, every Subversion (or git, or bzr, or hg, or CVS) repository I’ve ever gotten code from has a big disclaimer that says “This might be broken, don’t expect it to work.” Even Emacs has that and it has always worked. I guess this sort of thing is expected in the free software community whereas it is part of a huge scheme of denial in the non-free software community (if you can call it a community).
The other thing that Spolsky doesn’t seem to get is Unix. What Subversion does is model a Unix filesystem hierarchy and record the changes to that filesystem hierarchy. One of the beautiful things about Unix is that the filesystem hierarchy is significant, i.e. it means something. Subversion knows that and it does a damn good job of exploiting all the beauty of it. Those of us who can tell that Unix is The Right Thing are always going to have a hard time explaining how simply beautiful it is. Subversion has obviously spread beyond the “worse is better” community, and people out there often just don’t get it.
A little background
If you’re one of my non-programming friends or you’ve never used version control, or are thinking about it: Version control is a scheme for recording changes to a set of files. For example you can keep track of changes to documents, program code, or basic directory structures. If someone makes a change to a program and introduces a bug, you can undo it, in a way.
For a long time the only game in town was a set of programs called CVS (for Concurrent Version System). CVS was cool in its time but had a number of problems, so instead of improving it beyond all recognition, a team of developers created a beefed up, slightly more sophisticated one called Subversion.
With CVS and Subversion, you download (“check out”) code from a centralized repository (a database system on a server somewhere) that everybody checks their code into and out of. The repository is a centralized place for development. This model does have some shortcomings, though none that are completely damning; it’s still good for many types of projects.
As an alternative the Linux Kernel developers and a few others developed distributed version control systems, where every developer has his own “repository” locally where he or she checks in changes to code. To communicate changes to others, or get theirs, you “push” and “pull” changes, respectively. This has a number of advantages, but again it’s not a panacea. It’s good for some projects whereas Subversion is better for others.
For the kind of programming I do, Subversion is my choice. Also for my homepage, I use Subversion because the directory structure of my webpages is very important. However, for my configuration files and a writing project that I expect is years away from publication, I use Mercurial.
The unfortunate thing about distributed version control is that it’s a fad and therefore everybody’s raving about it and dissing the perfectly good system of centralized version control. I think that Mercurial and git are better than a fad, but I don’t think they solve every problem the way some people do. They start referring to decentralized systems as “modern.”
About the author
Joel Adamson is a graduate student in evolutionary biology; he uses Subversion and Mercurial for managing his projects.