Why We’re Not Switching to Git
July 5th, 2008
I got the following a couple of days ago from a colleague in the US:
Our development teams are debating the use of GIT vs SVN. [Project name] has standardized on SVN, but some of the projects are considering GIT. Do you have an opinion on their relative merits, particularly for computational science and engineering applications?
It’s a timely question—two of my best students are keen to switch us from Subversion to Git, and claim the latter makes them much more productive. I’ve decided we’re not going to (not before the end of 2009, anyway) for a couple of reasons:
- Documentation: there’s a ton of good stuff about SVN, but Git’s docs are still spotty in places. I’m reviewing an early draft of a book about it, and that’ll go a long way toward closing the gap, but it’s not going to be ready until early 2009.
- Supporting tools: we delayed switching from CVS to SVN until the Eclipse and Visual Studio plugins for the latter were solid, and we’re going to delay switching to something else (such as Git) until support for it is as ubiquitous, and as dependable. Again, that probably means some time in 2009.
- Reality check: we’ve already had one big snafu due to a developer (a bright one) creating lots of local branches, losing track of his work, then having the hard drive die. Fans of fully distributed version control don’t seem to take this into account when talking about relative productivity, and I think it’s easier to fall into bad habits when there isn’t the visibility of a central repository.
- Backing the wrong horse: Git seems to be the most popular VCS of its kind right now, but there are several others, and it’s not yet clear which is going to dominate. Having chosen Python for my web programming projects, only to watch Ruby on Rails grow by leaps and bounds, I’m willing to wait a while to see which horse is going to win the race before placing my bet.
Later: see also this guide to distributed version control systems.
#3 points out a serious misconception that lots of people trip over: Version control software is not a backup system.
There are enough cheap options now (rsync, Time Machine, CrashPlan, Mozy, etc) that no one who uses their computer for real work should be running without automated, daily (or more frequent) backups.
Centralized version control systems do help by keeping information on better maintained servers (which hopefully have a backup system), but they don’t really solve the problem. Everything up to the last commit might be saved on the server if your workstation drive dies, but anything else you were working on is lost, along with your whole development environment.
This may be getting off topic, but I guess my point is that distributed version control systems are really highlighting how fragile and underprotected our workstations are.
Trac already has git and mercurial plugins…
There hasn’t been a moment when I wished you had promoted Ruby instead of Python. Python is also growing by leaps and bounds.
you can’t really place a bet after the race =]
Don’t buy the hype, RoR has not grown by “leaps and bounds”.
I’ve got to adimt that I’m finally on your side here Greg. There are a few reasons (especially #4), but this quote was what finally made me change my mind:
“It’s great! If I want to implement a new feature, I don’t need to have commit access at all. I have my own private copy of the repository, so I can write the whole thing by myself.”
From this post: http://blog.red-bean.com/sussman/?p=20
In related news, now that SVN 1.5 (complete with merge tracking) is out, one of the biggest reasons to use DVCSs (merging doesn’t suck) is gone, so we’ll see what happens… Who knows, maybe some smart professors *cough*cough* will even teach there students how to use it well?
Your first two reasons are good; documentation and tool integration support are certainly sufficient concerns in themselves to resist the pull toward a new tool.
As for the “local branches can be lost” scenario, this is one of the primary reasons why I use Bazaar (http://bazaar-vcs.org/) for all my projects.
It’s fully distributed, but also has elegant support for a centralised workflow (called “checkout”, http://bazaar-vcs.org/CheckoutTutorial) that can be easily switched to and from distributed mode so you’re not stranded if you don’t have access to the central repository.
I highly recommend you consider Bazaar when it comes time to look again at a distributed VCS. (As a bonus for you, it’s written entirely in Python
Well, if we’re going to invoke Sussman, I have to point out
http://blog.red-bean.com/sussman/?p=90
Quote (from another svn developer): “I’m pretty confident that, for a new open
source project of non-huge size, I would not choose Subversion to host it”
@David: Did your read some of the comments? Graydon’s comment ( http://blog.red-bean.com/sussman/?p=20#comment-103 ) is pretty good at describing why code-bombing is a social issue and not a technical one.
#2 looks the most relevant to me. The tools for DVCSs are quite immature, so you need to use the system continuously to keep all the commands and parameters to them in your head. With CVS/SVN, you can just use a GUI for everything.
It doesn’t have to be an either-or choice. At least Bazaar has a bzr-svn plugin that lets you operate transparently on a Subversion repository (checkout/branch from it, commit to it), so I don’t really care any more whether somebody uses Subversion or Bazaar, I just branch from them and am done.
You could do like mozilla and test the three DVCSs for a while to see if any fits.
But you have some good points for not doing anything, except for #4. RoR is really not that widely used, Zope and Django by themselves are strong competition.
@Dmitri, @Jeff: Yes, I’m quite well aware that the problems are social, not technical, and that there aren’t very many compelling reasons to start a project on SVN these days. I also completely agree.
I guess it wasn’t clear that I’m thinking about the case of a classroom environment with DrProject (I _believe_ that’s what Greg is talking about)… And in that case it’s good to learn about social issues, but if technology can help mitigate them, all the better.