Why I Still Use Subversion: Some Qualms I Have with Git

By | August 2, 2013

Beginning about a couple years ago, I noticed a trend in choice of revision control system. Prior to then, pretty much everyone used Subversion (SVN) except for a few “cool people” who used Git, Bazaar or Mercurial (Hg). And then a transition. Slowly but steadily, Git grew to become the standard as major projects like KDE and Stellarium transitioned from their SVN repositories to Git. Sometime in the early 2011, it rocketed past Subversion in popularity on Debian, and most likely in general as well.

Git shot past SVN in popularity on Debian in 2011.

Git shot past SVN in popularity on Debian in 2011. Add the green and red together to find the true number of Git users. Source: Debian’s popularity-contest package

The Git page comparing itself with SVN certainly suggests I should, and there’s no SVN equivalent rebutting it. A quick search on Google reveals that nearly everyone else has also come to the same conclusion that Git is better than SVN with plenty of bloggers like this fully convinced Git is the way to go. So the real question then becomes why I still haven’t switched. The fact is, that while I do have my occasional qualms with Subversion, most of them are quite superficial, and some of the (also mostly superficial) qualms I have with Git, for me, makes up the difference with whatever advantages Git had over SVN.

Qualm #1: Git has no revision numbers

It’s one of the first things I came across when trying out Git — it doesn’t have revision numbers. Instead, each revision is specified with a hash like c24b287 or 64a3107. I guess most developers don’t really care, and to be fair, it’s a very minor issue. But for me, if 2 revisions are ever to be discussed or compared, I’d really like to know which came first without having to get that data separately where I could lose track of which revision’s which. And that’s enough for me to stick with Subversion.

Qualm #2: Can’t Clone Part of a Repository

This one’s a more serious than the one above because it has the potential to greatly annoy users who just want to checkout a copy of the source code from the repository. This is especially true with my projects which tend to deal with large data files that may change with duplicates or near duplicates across several branches. So instead of downloading, say 200 MB from just the trunk branch, users may find themselves downloading > 1GB due to the other branches. I guess I shouldn’t really care about this issue since I’m not the one who’s affected.

Except when I myself need to clone a repo by someone else, expecting a 5 MB download and ending up getting 50 MB of stuff I don’t need. Nowadays, if I see interesting source code in a Git repository, I’m always a bit reluctant to clone the repo unless I’m sure the code’s really interesting. Since I can barely stand doing that myself, I certainly can’t really allow my users to suffer the same ordeal if I don’t want to lose them right away. (And yes, of course I make source distributions available, but there will be always many who want nothing but the latest and greatest…) So…I can’t use Git. Actually, I probably overexaggerated the problem by a couple times and most users probably wouldn’t care either way because they have fast internet connections, but I care since I’ve experienced the “suffering” of having to waste endless minutes at the computer waiting for stuff to download that I don’t even want. So that’s my reasoning.

Qualms #3, 4, 5, …

I don’t really have that many notable qualms with Git. Maybe it’s because the developers designed it well enough for me to not have any more, or maybe it’s because I haven’t used it enough. Indeed, I certainly haven’t used Git enough to make a fair comparison, but that wasn’t my intent anyway. Besides those two “deal-breaker” problems for me, the rest should really have no bearing at all (not even as little as my reasons above might) on whether anyone else should use Git and are superficial enough to make my qualms above look like major disasters in Git’s design which they clearly are not ranging from who to support (Linus Torvalds vs. Apache) and their idealogical differences. I’ll just keep that to myself to avoid another round of unending (and for that matter, unendable)controversy.

In any case, if I hadn’t made my point clear enough, I’m staying with Subversion. It’s working perfectly fine right now and has always worked fine for me. I don’t exactly agree with the “if it ain’t broke, don’t fix it” mantra, but I certainly don’t support the “if it ain’t broke, fix it ’til it is” one. For me, switching to Git would be the latter. But Subversion isn’t broken for me. Its speed is just fine, and I have no issues with its somewhat basic tagging system since it doesn’t affect users’ download size. If it’s broken for you, and you’re just unhappy with its design or performance, you’ just might find Git to your liking, so take a look if you haven’t already. I’ve made my point; you go make yours.

Leave a Reply

Your email address will not be published. Required fields are marked *