In the small ecosystem of the development community that I spend my time in, Git is picking up steam as the SCM of choice. This migration that I have seen seems to be primarily for open source projects.  Recently Donn Felker made the statement "I think git (or something similar) is the future of VCS." on Twitter. I respect Donn, he's very smart, but is he right?

I see the advantages for open source projects where development is distributed. The software was developed initially to handle the development of the Linux Kernel specifically. In this way, it lends itself to the needs of this type of development. So if we extrapolate that further, it should be optimal for any kind of active open source development which are the types of projects with the largest liklihood of recieving updates from remote developers. I can also see the benefits of having a full repository locally as I keep repositories on a usb stick so that when working during my commute, I can checking, branch, or tag without having to wait for an internet connection. So even as a single developer, Git has advantages for me. But what about corporate America? Will we see wide spread adoption in these situations?

My guess is no, it isn't likely. I'm writing this as someone who has never used Git, and does not completely grok how Git or Distributed Source Control works. But here are the questions that I ask myself when looking at this problem.  I've worked at too many places where the development hardware was unnecessarily under-spec'd.  Getting anything over a 100GB of storage is difficult. Storage gets cheaper constantly, yet even with new machines the HDD's are laughably small. So, would we ever want to have full version history copied local? Hard to say, most repositories are probably quite small. The largest I have experience with is 2.5GB which is probably an extreme case with lots of binary files. Not unreasonable, even with a small harddrive. But I'd be curious to know what the average monthly growth of that repository is now.

My next question is around frequency of check-ins. As good developers, we know we should check in often, and if we do that with Git, that would maybe mean doing it often to your local copy, and then only checking into the central server once a feature is completed? I don't know, I guess a policy could be created and then ignored around this matter. How much code do companies want to risk on developer desktops/laptops? In this scenario, developers could be doing the "right thing" by checking in often, but they have another step complete... the actual commit to the central server. The way around this is of course to commit to the central server each time, and this could be me not understanding how distributed source control works, but that's double the work. Also, organizations want to have control over backups, and if they don't know how much source code is only sitting in developers local repositories, they don't know how vulnerable they are. Granted, with so many versions of the repository, that in a way is like backup, but each of the developers is vulnerable to losing the functionality they are working on if they have a harddrive failure, and even though they may have "checked in" the code, they lost it. Beyond that, I think that most development groups simply work in a process that Subversion is a better fit for. Similarly, most open source projects have processes that are a better fit for something like Git.

I'm sure some development shops with lots of talent will pick up Git and start using it. However, for the average organizations IT group, it seems unlikely that it will take off in my opinion. I remember when a company I worked for was looking to move away from Visual Source Safe, and we had two options, Subversion and Perforce. One of my arguments for Subversion was the fact that it was so prevelent in the open source community, that I was likely to encounter it again, and therefor it was a better skillset for me to have. And every job I've had since has used Subversion. To be fair, I did interview at a place that used Perforce, but I ended up passing on the job (the SCM had nothing to do with it). So, I know that I will end up working with and trying to grok Git, probably in the near future. At the end of the day, it is about choosing the right tool for the job. I think Subversion will probably be the right tool for most peoples day jobs, but there will probably be a lot more Git in the afterhours.