January 16th, 2009

And argument for using Git...from Debian

I find this very interesting.


Out of Debian packages which self-identify as using a version control system, git is the most popular distributed source control system. Caveats apply of course, but this is interesting in that that preference is somewhat organic in nature, as Debian offers its package maintainers a choice as to which vcs to use. SVN is still the most popular overall, and that's not surprising since the bulk of the existing packages were using svn before the dvcs options where available. This will be an interesting graph to watch over the next 6 months or so.

I wonder if we see a similar sort of preference in our fedorahosted.org services split. Fedorahosted offers git,bzr,hg and svn as service offerings and projects choose which service they want to use. On a project count basis at fedorahosted is git showing up as strongly as an overall preference to other dcvs as Debian's packaging tags are showing there?

Here's the fedorahosted.org breakdown from jeremy
242 git repos, 71 svn, 33 hg and 6 bzr
and 1 mtn repo according to "chops" mcgrath

So at fedorahosted where all the upstream project maintainers get to choose which dvcs they want with no penalty as to service integration (as far as I am aware) git is way way out in front of the other dvcs. Fedora as a project doesn't have a dog in the race as to which dcvs is better..yet. We will be dragged into moving to a dvcs for our distribution packaging at some point..its pretty much unavoidable...but not yet.

At fedorahosted, individual project leads are independently choosing which dvcs to use and most are choosing git. I think that says something significant about the importance of making sure you have git available as a service option for your online code collaboration service business moving forward. All arguments for or against the technical superiority for any specific dvcs technology makes for a nice discussion for project developers who need to choose a dvcs service. But if you are a trying to build a service business around collaborative services can you ignore git in your service offerings and stay competitive?