Posted on Saturday, April 5th, 2008 at 5:38pm by Rob Wilkerson
There’s been a lot of ambient (and not so ambient) noise in the geeky corners where I often linger about Git. There seems to be some sort of mass exodus underway as folks indicate that they have, or are planning to, move away from Subversion for their source control needs and I have to admit that I’m feeling a little ignorant.
I haven’t used Git (yet?), but I’ve been doing some reading and I still don’t quite understand the infatuation. Don’t get me wrong, it looks like there are some nice features, but at what cost?
The key difference between the two systems seems to be the model itself. Where Subversion offers a centralized model, Git provides a decentralized model. At the risk of over simplification, this means that Git offers each developer their very own, fully autonomous copy of the entire repository. With Subversion, each developer has their own working copy, but commits changes to a single, central repository.
The arguments in favor of the decentralized approach, as I understand them, include:
Speed
Okay, I like speed. Since each developer has a local copy of the entire repository, fundamental actions like diff, commit, etc. are all local. That’s always going to be faster. Fast is good.
That said, server interaction with Subversion isn’t exactly excessive. Developers work in local working directories and only interact with the server in short bursts. I’ve never found myself thinking, “Great Scott, this is unbearably slow.” For me, at least, this seems like a fix for something that isn’t broken.
Smaller Space Requirement
A Subversion working directory contains two copies of the entire code base. One that is actually being worked on and another tucked away in the .svn directory. I remember reading somewhere that the Mozilla repository required ~12Gb of storage in Subversion and ~420Mb in Git.
This is a substantial difference, to be sure, but there’s a phrase that everyone in technology hears on a daily basis: storage is cheap. That can’t be a compelling argument for one problem and not for another, so I don’t think this difference is one that’s going to precipitate a switch all by itself.
Line Ending Conversion
This is an important factor for mixed environment teams. Evidently early versions of Git made no changes and more recent version handle the conversion automatically. That decisioning is manual with Subversion, but is spectacularly easy to do by making a simple change to ~/.subversion/config for each file extension impacted to specify the line ending desired:
*.sh = svn:eol-style=LF;
Other Concerns
In addition to the fact that none of the arguments presented in favor of Git are particularly compelling to me, at least not the way I understand them, I have a few other concerns about the decentralized model. Actually, they probably all roll up to a single concern – accountability.
Every project I’ve worked on requires some level of immediate or semi-immediate accountability. A project manager who needs to ensure that an appropriate amount of progress has been made against the project plan, a boss who needs to spot review code or maybe a continuous integration process that needs regular repository updates so that its not just rebuilding the same old thing.
It seems like the decentralization of the repository would hamper those efforts. Sure, it can be done, but it would have to be done with process.
I also wonder if, in a team environment, having too many people doing too much of their own thing for intervals that stretch too long would make effective merges all but impossible. It seems like it would.
Am I missing something? Are there additional benefits? Is there anything else I haven’t even mentioned that I should be considering? I’d love to hear from other source control users who have moved to Git from Subversion.
subversion, source control
