Saturday, August 20, 2005

Distributed Revision Control No Threat, Pt. I

One of the things that Canonical is doing is providing bazaar imports of cvs and subversion archives. These imports (The SuperMirror & Bazaar Imports) give uses a way to try out Bazaar 1.x with projects that already have a long history. Goodies from all walks of life are present: GNU, Gnome, KDE, independant projects. This really gives user a great opportunity to try out Bazaar with existing projects and see how Bazaar meets their needs.

Unfortunately some people are a little worried that these imports give people the power to fork projects. The logic goes something like this: With a distributed revision control system any user can branch a project and not offer merges back into the mainline. Most developers want to protect our software against questionable design, poor workmanship and dangerous thoughts. This goal is an admirable one that most people should subscribe to and one I fully support. However, as with most things, the means one uses in order to justify the ends is just as important as the ends themselves.

Locking people out of revision control is not the cure to ensure the cohesiveness of a project. If you run certain revision control systems (cvs and subversion come to mind) you can dictate which people can and can't use revision control (and in which ways). This barrier to entry is sufficient to discourage some projects from forking into two seperate projects.

Using this sort of tactic is not the right way to ensure the cohesiveness of a project. This power play suffers the same consequences of all power plays: The best politicians win over the best meritocrats. The person that holds the control over the RCS gets to decide who has the ability to develop with the benefits of a RCS. Those that toe the line get favored, those that disagree are held back.

Several years ago Eric Raymond wrote a paper comparing the differences between two styles of development: the cathedral style and the bazaar style. Whether or not one agrees with Raymond's paper, one thing is certainly true: A non-distributed revision control system is the establishment of a cathedral type system. With the power of deciding which people can commit and which people can read archives comes the ability to enforce decisions about which code will be developed when and by whom.

Everybody gets to play in a distributed revision control system. Any person can take the official codebase, study it, learn from it, locally branch it and experiment with it. Each person can develop at their own rate, knowing that they can relatively easily merge in the latest and greatest from the official mainline. When their code is ready to be pulled in and supported by mainline the new developer can send a merge request to the official developers with code that is current with today's codebase changes.

So far we've established that controlling access to revision control is a power play. Some developers are willing to accept this cost to prevent the forking of the community. Tomorrow I'll explain the real factors preventing forking (hint: it has little to do with your choice of revision control system)


Post a Comment

<< Home