Home > Programming, Tools, Version Control > Subversion Causes Brain Damage (according to Joel Spolsky)

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.

  1. Erik
    February 11, 2011 at 15:14

    When I read Joels arcticle I got the impression they didn’t understand
    what tagging/branching is for and that it is cheap with subversion.
    If I do not want to get a stomach ulcer because of Mike I create
    a private branch and I can check in broken stuff anytime.
    Then I can run tests (again) on that branch and if everything works fine
    I merge it with the real branch (which should never be trunk anyway in
    big projects?).

    My latest customer had lots of non-developers that have to touch some
    build files once in a while. They do not want to clone a xxx GB repository
    to touch a small parameter file. And they actually cannot do so because
    they work on a unix box with a tight disk quota.
    So checking out only a small subdirectory is vital for them to work.

    But actually that very customer didn’t understand subversion too.
    No branching, no tagging, and therefore lots of stupid code freezes.
    And you listed it too: no proper (automated) ways to test code
    before a checkin.

    Like

    • February 12, 2011 at 19:19

      Yeah, the detractors clearly didn’t understand version control principles anyway. We must be wary of trusting stuff just because it’s on the web. I call it a “stage effect:” you can be any skill level of musician, but as soon as you get on stage, you have a certain level of expertise in the eyes of many audience members. No matter that stage is basically an open mic with a pick-up band, my banjo playing was suddenly “innovative” and “awe-inspiring.” We get the same thing from reading stuff on the web: it has not been peer-reviewed, nor passed the regular standards for accuracy of published material, yet people will read it with a certain level of trust. That goes for anybody reading my blog too.

      What I don’t get is how you would understand git or Bazaar without understand Subversion first. That’s the route I chose, so I will find it hard to know it any other way. I guess I still need to watch Linus’ Tech Talk.

      Like

  1. September 4, 2010 at 06:37
  2. November 29, 2010 at 07:22

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: