Why Subversion is better than Git

A while back I had to make a decision, as the most senior developer on a team, if we should stick with the Git version control system. Git is extremely popular these days in the open source community. It was developed by Linus Torvalds to manage the Linux source code. And everyone wants to be as cool as Linus.

But hold on. Linux is not your average project. Certainly not the average project I work on. Linux is programmed by thousands of developers all over the world, with a hierarchy of committers and reviewers. Linux has a large volume of code. People using and making modifications to the source code are programmers, who can handle complex concepts who know why merge conflicts occur and when to use feature branches, release branches, etc.

My world looks different. I sit in an office with 2-3 onsite people. Some of them are graphics people who have a good sense of what looks good, but not a good grasp of resolving merge conflicts using vi. Some of them are managers, bosses, project leaders, product creators, who should be enabled to edit certain things such as wording, but who certainly won't make much effort to learn anything new and will simply order me to do their wording changes myself if the system doesn't work to their liking. This may not be everyone's world, but it's my world.

So it would be surprising to find that one system fits all sizes (although certainly not impossible, look at TCP/IP!). But it certainly can't be assumed without evidence or investigation, that a system working for one world is the best solution for the other.

What do I want from a version control system? I want the following, in the following order (most important first):

  1. A system which can manage files between multiple users. A Windows share would suffice for this requirement. What I don't want is me having to send a file to someone via email, me changing the file, them sending a changed version 2 weeks later back to me, and another 2 weeks after that, and me having to manually work out what changed when, and trying to make a combined version in a text editor. Or me working on my codebase and my colleague working on their codebase, and then 1 month later having to try and merge the results in a text editor.
  2. History. Who did what when, and why? If something breaks, who did it? Why did they do it? If I revert their change, what will I break? The ability to revert to a previous version.
  3. Branches. If more than one person creates a new feature, I want to be able to check stuff in, they check stuff out. But it shouldn't go live yet. But live bugfixes need to happen. Multiple people could work on multiple different features, and one merges each feature into the "to release" history stream when they're ready: in whatever order they become ready.
  4. Being able to create patches of changes, send them to other people, have them review them, etc. Actually I don't need this functionality at all, but maybe I would if I worked on open source software.

OK let's look at objectives #1 and #2, my most important objectives. As stated above, as many people should be using the system as possible (incl. non programming roles), in order to make me send/receive emails of various versions of stuff as infrequently as possible. Here's my experience in this area:

Subversion is good because it's simple and it has a good user-interface. Having a good user-interface is made possible (although in no way guaranteed!) by it being simple. Errors don't happen often (as it's easy for the user to have a model of how it works consistent with how it does actually work) and if they do, errors are clear and understandable, and often include a description of what to do next. Tortoise SVN is integrated with Windows Explorer and works perfectly, I think everyone who's ever used it would agree. (Is there anything equivalent for Git?)

Subversion 1.5 (the latest version) even supports some fancy Git features. You can import all the changes from one branch onto another branch ("rebasing") and it remembers which its imported, so next time you do them, it won't import them again. You can "cherry pick", i.e. decide that a particular revision should be imported from one branch to another, but no revisions before or after it: useful for applying a particular bug fix from development to live, for example, without carrying across any other new features. So there's really nothing Subversion doesn't do, which I would need.

So I took the decision to convert our repository away from the modern shiny "git" system, into the nearly-legacy (if you read open-source evangelists!) well-engineered easy-to-use Subversion. I haven't looked back.

In addition (independent of distributed vs central source repositories), Subversion has so many well-engineered practical features:

A few positive things to say about Git vs Subversion:

By the way, when converting between version control systems:

(Subversion 1.5, Git 1.5)

P.S. I recently created a nerdy privacy-respecting tool called When Will I Run Out Of Money? It's available for free if you want to check it out.

This article is © Adrian Smith.
It was originally published on 3 Feb 2009
More on: VCS