Danie Roux

People person, change agent. Journeyer through problem and solution space. Interested in being interested.

Danie Roux header image 2

Distributed version control: The perfect fit for the bazaar

September 15th, 2005 · No Comments · general

The problem: Client-Server needs a gatekeeper

CVS has been the preferred version control system for Open Source projects for a very long time now. CVS in its current form was created in 1989! It has a number of limitations, most notably in renaming files and directories (you can’t). So some core developers of CVS came together and created Subversion to fix the issues in CVS.

Subversion is excellent, I use it daily at work where we manage a lot of projects with a lot of code. It has a number of cool features that fits in well with the requirements of my work environment. Restricting access to certain repositories and even certain parts of a repository is easy, for example.

It is great to have all the code in a centralized repository, centrally managed with the gatekeeper of the cathedral handing out access to those that are worthy and blessed.

But wait, Open Source need no such gatekeeper. The code is open for all to see, modify, redistribute and even badly mangle. As esr says in the Cathedral and the Bazaar:

“Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.”

So why are we using a version control system that insists on handing out write access to the repository? Sure, you need quality control. Meritocracy is a good model.

But what if someone wants to take the code in a direction that does not immediately seem like a good idea? Or just a direction no lead developer is interested in?

Well, that someone is more than welcome to do so. The problem is that that causes a fork. Two code bases, two groups. If they get merged back in the future, it is difficult to retain the code history of each project.

The solution

The solution is to allow the developers to make their own branches of the code, without anyone’s permission. Distributed Version Control Systems makes this possible.

If code is stored in a DVCS, anyone can decide to branch and start working on that branch. The big advantage is that early adopters can choose to start using this new branch and provide the rapid feedback that could shape this branch into something that could be folded back into the main tree.

The flipside of the coin is: No permission is needed to fold back code in a branch back into the main branch (politeness aside).

So what we have then is a complete bazaar of code, where code and ideas flow from one group to a other and back again. Where one main group becomes a two smaller groups and dynamically merge back to one at some later stage. With full history of all the events and all the changes.

DVCS in action

Darcs-git started me thinking on this. It started of as an unsactioned, unblessed fork/branch from darcs. It became stable enough to be merged back into darcs-unstable. This is the bazaar working in all its glory.

Disadvantages of DVCS

Since there is no single location of the code, there is no single main trunk either. The only way to have such a trunk is by convention. Naming, or otherwise. This can be confusing for new users, but in reality its not a problem.

The other problem with DVCS is that it is not widely understood or trusted. That will of course change with time as more and more people turn towards it.

Current DVCS systems

A great overview of current systems is David A. Wheeler’s Comments on Open Source Software / Free Software (OSS/FS) Software Configuration Management (SCM) Systems.

Tags: ····

0 responses so far ↓

  • There are no comments yet...Kick things off by filling out the form below.

Leave a Comment