Version Control Changes
Nathan Yergler, April 1st, 2008
I alluded to it in my last post and wanted to provide some more details and context on the changes we’re making (have made) to our source control systems. Since I started working on CC code in late 2003 we’ve hosted our source repository in the CC Tools project at Sourceforge.net, first in CVS, later in Subversion. Sourceforge.net has been great in one major respect — to the best of my knowledge we’ve never had a data loss issue. Of course, many times using Sourceforge has also felt like something to endure rather than appreciate. It was while enduring the delayed availability of Subversion that we decided to move the ccPublisher code base to Berlios.de, which was marginally better.
Since the beginning of 2008 a few things have conspired to finally push us over the edge and decide to leave Sourceforge.net behind. On one hand we’ve been itching to work with a distributed version control system (we wound up choosing Git). While using Sourceforge didn’t rule that out, I wanted to make sure that we had a place to publish our repositories publicly, both for redundancy and transparency. Accepting this as a task just made me more amenable to also creating a place to publish a Subversion repository. The other event was a morning of outages (again) on Sourceforge’s Subversion server. I was trying to commit updates to the license deeds (just over 20,000 files updated), and the operation kept failing mid-way through. Note that this is a commit that can take up to 12 hours when successful.
Two days later we were cutting over to a new system, hosted at code.creativecommons.org. We turned off write access to the Sourceforge repository, synced it, and asked contributors for public keys, which we’re using for authentication. The new system supports both Git and Subversion, public key authentication for committers (using the pretty slick gitosis on the git side) and is fast. Really, really, really fast when compared to our Sourceforge repository.
Total estimated time for testing and deployment: 2 person-days.
Luke Hoersten
April 2nd, 2008 at 18:13 +0000Excellent move Nathan. It’s never an easy call to move to a whole new revision control system/model when you have such a large code base (or in your case, large composition of code bases). When I worked on CC related stuff, it was definitely a hurtle to work with SVN and especially SF (which was constantly slow or down). VCSs should facilitate not hinder and I think DVCSs do that.
Git and DVCSs in general can be slightly more challenging for developers to learn, especially after being so used to CVS or SVN. For OS X users, there’s an awesome GUI called GitNub hosted at GitHub. For learning DVCSs in general, here’s a collection of resources, such as guides and tech talks. Linus’ tech talk is a must-see.
Good luck with the migration!
Jakub Narebski
April 5th, 2008 at 10:43 +0000It looks like git web interface doesn’t work (yet?), at least link at code.creativecommons.org named “web view” for Git, http://code.creativecommons.org/viewgit returns 404 Not Found error.
Issue Tracking at code.creativecommons.org - Creative Commons
September 5th, 2008 at 21:19 +0000[...] the trend started when we moved our source repository, today we’re rolling out issue tracking on code.creativecommons.org. Our goals are two [...]
git-svn and svn:externals « yergler.net
July 21st, 2009 at 16:47 +0000[...] Creative Commons we’re a dual-[D]VCS shop. Since we started self-hosting our repositories last year we’ve been using both Subversion and git. The rationale was pragmatic more than [...]