bzr and centralised repositories

[Nicholas Nethercote]

Hi,

I'm following the Bazaar-NG development with interest.  I've read through 
the design documents, but I'm a bit unclear about how it would support 
centralised repositories (I have no experience with decentralised VCS).
Basically I'm interested in knowing how I could use Bazaar-NG for the 
projects I work on now, which is entirely selfish, but perhaps what 
follows might also provide a useful use-case for the Bazaar-NG developers.

The main project I work on is Valgrind.  We just switched from CVS to 
Subversion, which wasn't a very big change.  We have a centralised 
repository, of course.  There are about 7 developers who have commit 
access, 3-4 of whom do most of the development.  Most development is done 
on the HEAD.  We only use branches for maintaining stable releases, and 
only bug fixes go into those branches.  (And so such bug fixes have to get 
merged into both the stable branch and the HEAD, which is a chore.)  We 
can get away with this because there are few enough developers.  One 
consequence is that we have stable releases and development releases, and 
the development releases often get way ahead of the stable releases 
(because the development pace is quite fast and so large architectural 
changes still occur quite often), which is not ideal.

So that's how we work as a group. My personal way of working with SVN is 
that I usually have several versions of the HEAD checked out into several 
workspaces, which I call head1, head2, head3, etc.  I have multiple 
workspaces because I often work on more than one change at a time.  One 
nice thing is that I can just use "svn update" to keep these workspaces 
up-to-date with changes that are committed into the head.  This way I can 
run the regression tests just before committing and be fairly confident 
that my change hasn't broken anything.  An important thing is that when I 
run the regression tests in any of these directories, I'm testing the HEAD 
plus a single changeset.  I like doing that before committing, rather than 
testing and committing multiple changesets at once (which I think 
decentralised VCS systems might encourage, but I'm not sure).

This suits me fine because I almost always have network access.  Another 
Valgrind developer finds Subversion more frustrating because he likes to 
work on his laptop on the train, so he wants to be able to do offline 
development.  Because of this, he's a fan of BitKeeper.

I saw what Greg Hudson said at 
http://web.mit.edu/ghudson/thoughts/bitkeeper.whynot.  A lot of what he 
said sounded right to me, given our model of working.  It's unclear to me 
how my way of working would fit with Bazaar-NG, or how it could be 
adapted.  Would each workspace be a branch?  How would the branches be 
committed to the central repository? 
http://www.bazaar-ng.org/doc/shared-branches.html kind of covers this 
ground, but I still don't get the big picture.

What would be the benefits of Bazaar-NG for Valgrind over Subversion? 
Maybe there would be no great benefits.  Or maybe I can't see them because 
I'm so used to centralised VCS that I don't understand how decentralised 
VCS could help us -- ie. I don't realise what shortcomings of centralised 
VCS we're working around.  For example, maybe our very limited use of 
branching is because the branching and merging in centralised VCS systems 
is not very good.

I'd appreciate any feedback about this, and any pointers to information 
that could clarify things for me.  Thanks.

N