Whither goest thou, Version Control?

August 26, 2008 Jack Repenning

In the perennial debate over Version Control, the latest chapter is entitled "Centralized vs. Distributed" (sometimes also known as "Subversion vs. Git", though both flavors have other worthy representatives). For a while, Ben Collins-Sussman has been the lightning rod of the debate (his own fault, for thoughtful side-taking posts like this, this, this, this, and this). Now, a new Ben (Griffiths) steps into the ring with a really trenchant insight into the split.

Although I’m sensible of my inadequacy to comment in this area (not being named "Ben"), I have to say I had a real head-slappin’ moment when Ben tweeted about his new idea last night ("Ben the Second," that is). "Centralized Version Control (CVC) for teams, Distributed Version Control (DVC) for groups" really captures something about the respective situations … several things, in fact … and it’s particularly recognizable at the level of individual experience (as opposed to the compatible but rather stratospheric overview I recently blogged). Where "Ben 1st" didn’t actually say, but brushed perhaps a bit too close to saying, that "people who don’t do it my way are just dumb," the group/team perspective provided by "Ben 2nd" is both less … incendiary … and more useable.

Who doubts that Linux has been a spectacular accomplishment, and continues to be a vigorous, progressive movement?  (Hands, please?  Anybody? No? Thought not.) Who doubts that it’s largely powered by independents, that the workflows support and encourage the maximum possible "heads down in your own corner" contribution? And, if you haven’t thought much about it, give it a thought now: the version control tools, and the release management process, created and nurtured and built up and solidified that culture. It’s a group. It is, in fact, a group of groups.  Ben 2nd is right: Git is all about fostering such a community. You could do it with a CVC tool like Subversion, but no more effectively than you can remove wheel lug nuts with a hammer, if that’s all you have.

Conversely, if you want the benefits of resource planning, early warning when something goes sour, and commitments to roadmaps, features, and schedules, a CVC system will help you in ways you’d have to engineer for yourself atop DVC. Where DVC (and "The Linus Process" in particular) bias towards keeping work invisible to the rest of the world until it’s good enough to accept, CVC biases towards making everything visible from the beginning.

If you’re in the position of choosing a system for your project, maybe Ben 2nd’s "groups vs. teams" idea will help you decide.

Previous Article
Steering Subversion
Steering Subversion

When the Subversion project first launched, it was blessed to have something that many much older projects ...

Next Article
Contribution patterns in open source
Contribution patterns in open source

A month or so ago, Michael Ogawa published some fascinating and beautiful "home movies" on the commit patte...