the case for distributed revision control

in the world of revision control, the debate between centralized (cvs, svn, etc) and distributed (git, mercurial, bzr, etc) has been going on for a while. from the distributed camp i've heard arguments about the blessings of being able to branch wildly, of patch management bliss and of file storage formats.

recently i started using git for a few things and i have to say it is fast, compact and rather easy to use. (this is a combination other distributed rc's i've tried haven't offered) i've come to the personal conclusion that git is a very nice tool that may even be able to meet our demanding and whacky requirements in the kde project in a few years time. maybe sooner. and this got me thinking: why would we use such tools?

the answer came to me as i travelled to various locations on the planet this year.

the internet is absolutely core player in free software development. it is how we collaborate at every stage: irc, email and source sharing. email is just fine over a slow and intermittent connection but something like subversion is hellacious to try and use in such situations. since it requires you to be online to update and commit, it also means that you need to be online whenever you are doing development. there's also a non-trivial amount of network traffic that gets generated.

so where does my travelling fit into all this? i've been in a number of very populous countries where such internet connections simply aren't the norm, particularly not in private homes. which means using tools like subversion is a blocker to participation.

if we really want to reach out to people who have the knowledge, skills and drive to get involved but who have slow (by broadband standards) dial up access that they pay for by the minute we will need to move towards systems that allow people to work offline as much as possible.

for me, this is where tools such as git shine. you can work in your local repository without a network connection just fine, including committing, branching and the whole bit. you only need to go online to send patches and pull updates. patches by email are manageable even on dial up and git's speed means that pulling updates can be economical.

furthermore, git's on-disk storage format makes it friendly for use on systems with smaller disks and its performance makes it more than usable on slower systems. i haven't looked at its memory consumption, so perhaps that an achiles heal.

so, long story short: reaching out to the just-getting-wired world means we need to look beyond centralized online systems. until there's broadband everywhere, and that's not going to happen in the mid term, we may want to think about our tools in that light.

distributed bug systems are probably equally attractive for these same reasons.