Distributed Revision Control and Gnome

As pretty much everyone knows at this point, Gnome has migrated to Subversion for all of our source code management. As many subscribers to gnome-hackers are aware, a few hours before the twice delayed migration was about to start, a serious discussion arose debating the merits of a distributed RCS as opposed to our traditional centralized system.

Now, I am not against solid debate, but given the circumstances, I thought it was a little stupid, as Ross had already poured hours into working out the nuances of cvs2svn so that we could have a smooth transition.

SVK
That being said, I am a fan of distributed revision control, I feel more at liberty to experiment and be creative when I’m not messing up someone else’s system. Branches make more sense to me than patch’s, and my tendency to work wirelessly can make little things like checking commit logs a major pain, or even simple diffs. As a result, I have grown fond of both git and bzr, basically for the opposite reasons. But in my infatuation, I started to experiment and play around a little with the new SVN server, and found that enjoying the powerful merging tools of a Distributed RCS can still happen, even with a centralized server like we have.

My first sample is probably the most obvious, but also the least out there. If your new to the idea behind distributed revision control, this is a great first step. I’m talking about SVK, its a small set of wrapper scripts around Subversion that are conducive to developers maintaining a local copy of the source tree and its history, with generally just one local branch. Unlike something like git, this is meant to provide the developer with the speed benefits of a distributed system, as well as some simple local branching (and of course, complete compatibility with Subversion.)
The true beauty of SVK is its unobtrusive nature, no requests to crazed Sysadmins, no major restructuring of development habits, its more or less seamless. There is a great article in the SVK Wiki covering how to use SVK as a SVN mirror, but to give everyone an Idea of how easy it is.
Now, say I want to mirror gtk+, the steps go just like this:

svk mirror svn+ssh://kkubasik@svn.gnome.org/svn/gtk+/trunk //mirror/gtk+
svk sync //mirror/gtk+
svk cp //mirror/gtk+ //local/gtk+
mkdir ./kevins-gtk+
cd ./kevins-gtk+
svk co //local/gtk+

And that’s it! The thing that makes SVK noteworthy is its speedy integration with Subversion, and its simple nature. Most users just keep a ‘Mirror’ branch and a ‘Local’ branch, once you’ve finished what you wanted to, you just merge those branches, then push!

Bazaar-ng
Next I want to cover Bazaar-ng and its svn plug-in. Bazaar-ng (or bzr as its more commonly known) was created for the user who wants a more user friendly and comprehensive interface. Bzr is written and python, and compared to most other distributed systems, down right slow. But bzr is quick to make up the lost ground by supporting dozens of transfer protocols, including most centralized SCM systems. In addition, bzr possesses an incredibly versatile plug-in system, which the community has taken advantage of. This also makes bzr the first mainstream source code management solution that has a functional, incorporated, and incredibly useful Gui. (provided by the bzr-gtk plug-in for anyone who was wondering).
However, to summarize, bzr interacts well with subversion, treating it as any other branch, merging, pulling and committing, so should your project be looking for a more distributed feel without completely abandoning the translators and doc authors, they could still easily work out of subversion, with the developers merging with the central sever a couple of times a week.
Bzr is tough, for lack of a better description, its really fun to play with for a while, but it loses that novelty somewhat fast, as the long times (especially with the svn backends) start to pile up.

A Breif Moment of Git
Finally I wanted to cover the holies of holies, that’s right, git. In all honesty, I’m not sure what I could say about Git to anyone, it seems that everyone already has a strong opinion. Git is a great system, i have never once questioned the efficiency with which it does what it does. Git is fast, git is reliable, and its already proven itself in the ultimate stress test, since I’ve seen several posts about git over the past few days, I’ll keep this part shorter despite my fascination with git.
As some of you may know, git 1.4 ships with a handy little application called git-svn, which basically lets you use a powerful distributed system, where the SVN server is your sharing point.