bzr workflow

Neil Martinsen-Burrell nmb at
Mon Jun 8 21:19:48 BST 2009

On 2009-06-08 13:27 , Nagy Viktor wrote:
> Hi,
> even after using bzr for small scale, mainly private projects, I'm a bit
> confused about the recommended workflow, and now would like to start a
> shared work. Could you please clarify whether the following is fine, and
> give some replies to the questions at the end?
> how to share my work with a public trunk
> (1) get mainline
> $ bzr checkout bzr://trunk ~/trunk
> (2) start my own branch
> $ cd ~/trunk
> $ bzr branch ~/trunk ~/project1
> hack here
> (3) commit to branch
> $ bzr commit
> (4) merge to trunk
> $ cd ~/trunk
> $ bzr merge ~/project1
> $ bzr commit -m 'merged project1'
> the last commit made the changes public as well, given that it was a
> checkout not a branch of trunk
> questions:
> 1. is there anything to adjust on this workflow?

That looks just right to me.  For "decentralized with shared mainline" 
this is the recommended workflow (see 
Remember in (4) that you should be testing the result of the merge 
before committing it.  That is the point of making merge separate from 
the corresponding commit.

> 2. would it be better to use a --lightwieght checkout at (1)? why?

Only if you have guaranteed network connectivity to the mainline.  A 
bound branch (heavyweight checkout) should serve the same purpose of 
maintaining an exact mirror of the trunk locally, so long as you never 
use ``bzr unbind`` on ~/trunk.

> 3. would it be better to use bzr branch instead of bzr checkout in (1)? why?

Because it allows you full flexibility in your local mirror of the 
trunk.  If you *do* wish to develop locally directly in the trunk 
branch, then doing a ``bzr branch`` in (1) would allow you to do so. 
Note that you would then have to ``bzr push`` to publish your changes to 
the public trunk.  I do this frequently for working on a project with a 
trunk that is stored on a server while traveling with a laptop.  I make 
an initial branch that I use as a heavyweight checkout through the use 
of ``bzr bind``.  Then I can

$ bzr unbind
<take a train ride, hack, hack, hack, commiting all the way>
$ bzr push
$ bzr bind

> 4. is it possible to do proper merging/sharing without a local copy of
> trunk? (starting with $bzr branch bzr://trunk ~/myproject)

Yes, so long as your connectivity to bzr://trunk is good.  This also 
means that all merging has to be done on the branch before pushing the 
result back to the trunk, as you don't have a local copy of the trunk in 
which to do a merge.

> 5. how to follow trunk with project1? my idea is the following
> $ cd ~/project1
> $ bzr commit -m 'status before updating from trunk'
> $ cd ~/trunk
> $ bzr pull
> $ cd ~/project1
> $ bzr merge ~/trunk
> and then see what changed
> $ bzr status
> $ bzr diff
> hack here if needed
> $ bzr commit -m 'updated to trunk'

This is correct for following trunk. (See 
for more information on destributed development workflows).


More information about the bazaar mailing list