The case for distributed version control systems

Currently the parrot developers are discussion whether to ditch svn in favor of another distributed version control system, maybe git.

I'm not a very active parrot developer, so my opinion probably doesn't count that much, but I still want to share a story, and then my opinion.

The story

Back in 2007 I was bored. I read about Perl 6 and pugs, and decided to check it out. And then I found a broken link on the pugscode website. And since I tried to be a nice guy, and I was bored, I decided to inform the developers.

So I joined #perl6, and told the developers about the broken link. No more than 5 minutes later had the awesome Audrey Tang done three things:

1. Fixed the link.
2. Told me in which file of the repository the fix was.
3. Sent me a commit bit, so that I could make such fixes in future, too

I was very impressed by this display of openness, and stayed. Granted, there were some other reasons for staying too, but it did leave a very good impression.

Roughly a year (or maybe two) I had a doc patch for the Perl 5 core documentation. And I was surprised and disappointed to find that perl 5 (at that time locked into perforce) didn't even offer public read access to its version control system.

What we can learn

I've shared my short, romantic story with you because I think we can learn something from it: openness pays off, and being closed deters contributors.

I'm well aware that the parrot contributors can't hand out commit bits as openly as pugs (mostly for legal reasons; also it's a quite different stlye of development). But still a distributed version control system (DVCS) offers some of the openness that Audrey lured me with. With a DVCS the new developers can work just the same way as the core contributors, easily stack changes, bisect regressions and so on.

This social aspect of development is, in my opinion, a strong point for DVCSes. There are other reasons which speak for it; the strongest is probably that DVCS support both the central and the distributed development styles, while central CVS only support their own style.

Git vs. other DVCS

By now it should be clear that I propose to migrate to a distributed version control system. Any decent DVCS would be fine by me. I prefer git, because it's what I'm familiar with, and because it has very good performance characteristics.

I also like it because it has a feel similar feel to perl; many powerful built-ins, some of which are used day to day, others to explore if you have an usual problem or setup.

In short, I like git.