bzr and centralised repositories

[Benno]

On Wed Apr 20, 2005 at 17:31:09 +1000, Martin Pool wrote:
>On Tue, 2005-04-19 at 14:45 -0500, Nicholas Nethercote wrote:
>> 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).
>
>You can think of these checkouts as being a kind of degenerate private
>branch: you can work in parallel in each of them until your changes are
>ready to merge back to the rest of the world.  But they're degenerate
>branches because you can't version your own changes until you're ready
>to publish them.  In bzr you have the option of doing versioning in your
>own private branch before publishing your work.

Currently the way we are working with rsync, we actually get a copy of
your whole working, once bzr is totally up and running what would you see
as the `right way' for this to work? I would expect (coming from baz) to
be:

$ bzr branch bzr--mainline ./bzr-mywork
$ cd bzr-mywork
$ while <stuff_to_do>; do <stuff>; bzr commit; done
$ bzr send

And bzr-mywork could be a private bound branch, *or* could be independant.

FWIW, I prefer having my archive and working directory in different
places.  (E.g: one is backed up, one isn't, one is deleted often, one
isn't, one I have only one copy of, one I sometimes have multiple
copies of, one is publicly accessible, one isn't). I guess other
people work differently though.

Benno