Git will eat Subversion’s Lunch

As it stands, Git is going to eat Subversion’s lunch.

Because it is better, you ask?

No. Actually, Git kind of sucks in a number of ways. Right off the bat, it shoves about a zillion command line tools in your bin/ directory, many of which don’t work unless you go figure out what silly perl modules or something else are required.


But, still, Git will win unless the Subversion developers finally pull their head out of their ass and realize that opaque collections are much more than “just a Mac specific problem… just tar wrappers done right”.

To rephrase in a slightly less antagonistic fashion (Now, I owe several people a beer and an apology for that last paragraph): Subversion needs to focus on the user experience and not just on being a better CVS. There be innovation goin’ on and hiding behind “a better CVS” will only work for not terribly much longer.

Git will win because it is about 8 bazillion times easier to use because it doesn’t scatter administrivia crap throughout your work area.

This is just so fundamentally the right way to do stuff.

Why in bloody hell should the user have to think about mirroring the filesystem manually??!?!

Yet, that is exactly what Subversion, CVS, and Perforce force the user to do!

Stupid, stupid, stupid.

Try explaining to a user — to an artist, to your mother, to someone writing a damned presentation — why the frack they should have to go into some tool to either do what they have already done in the Finder (or Windows equivalent) or that even using the Finder (or Windows equivalent) will screw up their “workarea state”.

This isn’t about “wrappers” — about documents that are really directories. This is about convenience.

Give it 12 to 18 months. If Subversion doesn’t fix this — if Subversion doesn’t make it, like, not require lots of silly, repetitive, manual, error prone, operations that either mirror filesystem operations or require you to use one tool and not another — then Git will gain users in droves.

Users will switch not because Git is better than Subversion, but because Git is one whole hell of a lot easier to work with in the most common workflow — editing, adding, and deleting files.

Git doesn’t make you redo stuff that your computer is already quite good at doing. And, that, alone, will be enough to make users flock to it…

Fraser offers a much more techincal analysis of the differences. Personally, I desperately hope Subversion fixes this particular problem. Subversion is really and truly awesome in so many ways and I do not want to have to migrate repository software for at least another decade.

Fitz suggests — sort of — having a look at Mercurial.

Deprecated: link_pages is deprecated since version 2.1.0! Use wp_link_pages() instead. in /srv/www/friday/bbum/wp-includes/functions.php on line 4713

13 Responses to “Git will eat Subversion’s Lunch”

  1. Michael Rawdon says:

    and I do not want to have to migrate repository software for at least another decade.

    Yeah, I know how much you enjoyed it the last time…

  2. Fitz says:

    Feh. Git has perhaps the worst interface ever for a version control system. If you’d said Mercurial, I’d believe you, but since you said Git, I’m going to assume you’re just trolling.

  3. bbum says:

    LIke I said — I’m not interested in switching and, as such, I’m doing no more research than monitoring various RSS feeds and occasionally laughing at /.

    Maybe Mercurial gets it right and maybe it’ll be the one.

    As I said, Git is a pretty stupid in many ways…. but it completely runs circles around Subversion for ease of simple use!

    If Mercurial also doesn’t require the user to manually mirror filesystem crap or arbitrarily spew metadata across the workarea, it is a step up from Svn, too.

    I’ll probably move to one of the two to manage everything but source code, simply so I don’t have to deal with the tedious stupidity anymore.

  4. Mark Grimes says:

    Better never eats someone’s lunch otherwise CVS wouldn’t have survived all these years, nor Subversion, nor PHP, etc… I don’t know how popularity finds itself, but it never seems to be from an objective list of pros and cons, but instead entirely subjective.

    I know you don’t care to switch, and you’re looking at the Git phenonema at even higher view then Fraser which I felt was still somewhat biased and missed several of Git’s most valuable features which led to a meh stance about why any a la carte cocoa developer would need decentralization and what problems noone is solving git doesn’t solve either… but there are some nice aspects to Git.

    FWIW the git command tree is being condensed to less commands and MOST of the long list is just variants of calling things like git-svn or git svn. The rest is plumbing code, which is exposed but doesn’t have to be used. The fact that it’s there shouldn’t be intimidating, but I guess it is to some adopting it.

    Git 1.5.3 is in rc2 and has what i feel is a useful feature, git-stash, or the ability to save multiple dirty working copies so when you flip back and forth between your work and emmergent fixes you don’t have to reach a point of completion with the former code such that you have a nice functionally atomic commit… instead stash your code, flip branches, fix commit, flip back and recall your stash from the stash list.

    Fortunately Git doesn’t have to eat Subversion’s lunch in order for me to use Git behind Subversion — it’s like using a Mac in an office full of Windows computers (so offensive) — but it has the same feel, you look at the poor saps spending a week to merge a branch to trunk in a sizable project and you’re just glad it’s not you. You make a mistake on a commit but instead of reverting it and commiting it again you think I can just amend it — oh noes it’s a Subversion server and that requires svnadmin voodoo — but I digress. Git attacks many areas differently like tracking content and not files, using delta compression so that git repos+wc’s weigh in at nearly half the space of a svn wc alone, using hashes for commits that represent the entire history up to that commit to provide data integrity of the tree. Surely these things are more meaningful then a passing glance.

    I’ve totally embraced the notion of decentralization rather then found excuses for why I don’t need it — from offline development (a network connection is a silly requirement) to seamless version control of communal projects where I do not have a commit bit to being able to trade branches via sneakernet with the guy next door (handy in classified environments where code can come in but can’t go out) — you just can’t have a bidirectional connection in those regards and network cable is just that regardless of an anonymous read only presentation.

    Several years I’ve been pirched on a wobbly stick that is SVK because I was delusional and thought it was the only way I could sit behind Subversion without dealing with the svn client. In early-June I began looking for a replacement. It needed to be decentralized and have strong subversion integration. My list shrank to basically git and mercurial. I’m not a python hacker by trade so mercurial scored no points (not that i want to work on a scm anyway), and not on windows so much the same… but git scored for performance and storage format robustness and not being in a state of flux. My take on the research is Git and Mercurial share much of the same, but it comes down to which capability is more striking.

    Flat out merging in Subversion sucks almost as bad as it does in CVS, and appears to not be a panacea ( but in enough cases leave you in a manual merge tracking scenario.

    Apparently for reasons beyond my intelligence, Linus feels that the Subversion 1.5 merge tracking effort is ALSO horribly flawed and/or stupid. I’m not about to comb through it because I’ve had enough annoyance in the centralized scm workflow but more that I’m pretty comfortable (porcelain and some of plumbing) with git after daily use for a month across personal (git), work and community projects (git-svn)

    I think I’ve found enough reasons like evil twins and double merges that have driven me crazy with Subversion over time to where looking for a more sensible approach to version control among the popular opinion found me a wealth of other projects that pushed ahead of Subversion with the exception of CVS and VSS.

  5. Zachery Bir says:

    SVK does a reasonable job of getting out of the working copy’s way (not clobbering bundles’ SVN history, for instance) by consolidating the internals elsewhere. It also provides (if you want) disconnected local repositories. I’ve been using it for a year or so at my current job, and have decided to migrate (since it only affects the local environment) to switch to it. It leaves the server alone.

  6. Zachery Bir says:

    Mark: merge (rather, smerge) in SVK is also another strong point, and provides me close to the same confidence I had in CVS’ base/branch merging.

  7. Daniel Jalkut says:

    Fitz: more feh, and in blog format, please. The git hysteria has reached a boiling point where we need a blog-partee from the SVN camp.

  8. Mark Grimes says:


    I am pretty familiar with SVK, but I left SVK as did other mac developers for many reasons of which may not necessarily be the same as my reasons. For me it was ultimately no real support, and complete lack of confidence in the underpinnings and in turn the code I was putting into the system. I had no idea if my code would be intact, the tree would work (I’ve seen some clever bugs require tree rebuilding on more then a few occasions) and that my upstream commits wouldn’t make me look like a complete idiot to the SVN users on the other side… A few of those reasons might be:

    1. Way too many Perl layers for someone that is not a Perl hacker. This is a problem because the development team is so small that 99% of the time they can’t replicate your bug and or have the bandwidth to fix problems that they themselves aren’t experiencing.

    2. Due to #1, I have an outstanding SVK bug that will not pull like 20% of Subversion repositories — I noted this bug quite a long time ago. It is echoed by others notable in the SVK community. Yet others it is not showing up for (not using MacPorts). This bug has now manifested itself again, yet some developers are treating it like this is the first time they ever heard of it. C’mon, the maillist isn’t that large, it’s very low traffic. Apparently it only affects the MacPorts flavor — which also makes little sense since in the various threads the Perl versions are all the same. This was the showstopper for me — I want to work on my code, not the version control system in a language I never use. If you scan the list there are all sorts of inane errors that don’t give me confidence that what I put into the system is what I’m going to get out.

    3. Starmerge is not the important part in distributed development as much as rebasing… rebasing is a very important quality in git – it is available in the other alternate version control systems that only scm geeks seem to recognize. I’ve had all kinds of zany things go screwy with my mirror, i’d smerge upstream and it would attempt to update changes I didn’t as it to update even after I synced. When my tree got this messed up I’d find myself rebuilding the mirror. This is not sane, perhaps it comes from not understanding SVK well after years of use — but that’s pretty sad when I feel more confident with Git after a single month.

    4. SVK merge tickets are stored on the server and MOST post-commit hook emails Subversion projects use will display these prop mods on trunk in a most annoying way.

  9. Mark Grimes says:

    Oh c’mon Daniel 🙂

    What’s saddening about your response is NOONE from the Git camp as actually put their 2 cents in on ANY of these blogs, like you want the SVN camp to do. You’re an end user of SVN, so are 99% of the people that are reading these blog posts, but I’ve yet to see a clever retort to weigh in against Git, Mercurial, Bazaar-ng, Darcs or otherwise. I would hope that your years of Subversion use would be able to out-do any month romance with a new version control system, unless there’s actually some objective reasoning that prevents it.

    Subversion is well understood, these other ones aren’t (not by non-SCM nerds). The future milestones for Subversion (1.5 for fundamental merge tracking support, some later date/year in the future, decentralization) are also clearly understood. This isn’t supposed to be a religious war more than informing developers that they can have other features and capabilities today. You don’t even have to give up your SVN server if you don’t really want to — in Git’s case (can only speak from experience with Git) it’s just a client change out. You can even treat your decentralized system like a centralized system if you really want to (I think you’d actually like offline development and local branches though… most naysayers do once they taste the food)

    The change I’m seeing is that non-SCM nerds are starting to look at alternatives — Linus’ video brought the masses to evaluating alternative version control because we’ve spent decades of time settling with half baked solutions. It is offensive to say that, but the arguments for and against are well understood in present day. There is naturally a lot of apprehension to editor, shell and apparently SCM wars — but lets not pretend we don’t know how Subversion works in hopes that some smart person in a cape will swoop in and tell us everything is going to be OK someday.

  10. Mark Grimes says:

    Please forgive the long posts, I ramble — but I wanted to offer a better response to Daniel’s call for Subversion camaraderie to cool off the apparent new toy syndrome (even though this has been the state of the nation for years)…
    I admit myself that I am a lost leader in bringing up these arguments now since I tolerated SVK for so long instead of opening my eyes to see what existed… I’m embarrassed to think I could have been happier years ago instead of coming to this euphoric discovery that all of a sudden version control doesn’t have to be a pain in the ass.

    While I feel balancing the scales is a cop-out argument from being in both camps and seeing that scales are no where equally balanced, I tend to agree that the Subversion team explaining their efforts would be a nice thing, even I don’t have closed ears.. I would happy if a SVN developer could explain how the project has existed for so long without merge tracking — my hunch is that centralized models don’t encourage branching as much as decentralized since you are basically weighting down everyone’s repository with your experimental gunk unless they simply track trunk. In order for Subversion to go decentralized (which it will eventually, it’s a better solution not an alternate solution) they have to get merge tracking working first.

    While I still feel in all this Git advocacy that Git is just a sock puppet (could be Mercurial), I’d like to see Subversion at least re-architect how it lays out working copies without destroying history and hence how it deals with packing repos, tree integrity through a hash mechanism labeling of commits with optional naming versus arbitrarily incrementing an unimportant version number, remerging branches reliably (sans double commits), ability to cherry-pick reliably, amend old commits, rebase support (, … I’m not sure how the evil twin problem is being solved if it even is… but that’s a nasty one.

    This is a long list of features that already exist in other version control systems, hence the debate. These are all more than useful features but many would feel as necessary– many of the alternate projects have taken from each other here, so it’s not uncommon to find all these features that would be nice in Subversion in almost everything else. But again we’re back at just getting merge tracking working first without the 90% third-party solution that still often involves human intervention and commit language parsing.

  11. Links for 1/2/08 :: flickerbulb says:

    […] bbum’s weblog-o-mat » Blog Archive » Git will eat Subversion’s Lunch […]

  12. Switching to Git says:

    […] Git will eat Subversion’s Lunch by Bill Bumgarner […]

  13. Evaluation eines Versionierungssystems für die Master-Arbeit « b2b says:

    […] […]

Leave a Reply

Line and paragraph breaks automatic.
XHTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>