bzr and centralised repositories
Nicholas Nethercote
njn at cs.utexas.edu
Tue Apr 19 20:45:43 BST 2005
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
More information about the bazaar
mailing list