Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Wed, 4 Jun 2008 11:42:31 +0200

On Monday 02 June 2008 22:06, Andrew Johnson wrote:
> My current intentions are to convert the existing monolithic CVS
> repository into a series of Subversion repositories, split up by
> project.  We finally have the infrastructure set up here at APS to
> support SVN+Trac properly.
>
> *Before* anyone starts on about SVN not being a "modern distributed
> version control system", take a look at the Bazaar VCS and its bzr-svn
> plugin from http://bazaar-vcs.org/ which can transparently use SVN
> repositories and working copies while managing local branches.

I haven't tried bzr yet, but from the documentation it sounds like something 
one can work with. It is certainly a great improvement over Subversion. So 
why not make the full step and chose bzr and instead of relying on a mix of 
Subversion as 'back end' with the bzr-svn plugin as the 'user interface'?

The bzr-svn plugin leaves a number of questions open. Has anyone actually 
tried this out? http://bazaar-vcs.org/BzrPlugins markes it as beta, and 
there are some limitations listed at 
http://bazaar-vcs.org/BzrForeignBranches/Subversion (home page of the 
plugin). It also says there: "requires a couple of fixes to the Python 
bindings for Subversion that are only available in Subversion 1.5 and 
higher. Subversion 1.5 has not been released yet, but packages with the 
appropriate patches applied to older versions are available for some 
platforms." It is also unclear how large the (user-, developer-) community 
is behind this effort.

All this doesn't sound too convincing to me. And having one day to fall back 
to the Subversion 'back end' will leave us in a position that is barely 
better than the one now. This might sound harsh, but believe me, I've been 
through it. Of course Subversion fixes the most glaring deficiencies of CVS 
(e.g. properly handling directory and file renames and providing a reliable 
backend store). However, it does in no way solve the much deeper problem of 
how to effectively maintain separate branches of development.

I still think that Darcs offers by far the best approach for this. I won't 
bore you with marketing, just try it out and see for yourself. Let me just 
mention that Darcs-2.0 has been released about a month ago (fixing 
the 'exponential blow-up' problem on which Darcs used to 'hang up' when 
trying to merge deeply nested conflicts). A maintenance release (2.0.1) is 
due to come out pretty soon.

Cheers
Ben

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System