bzr workflow

[Neil Martinsen-Burrell]

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 
http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#workflows). 
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 
http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#organizing-branches 
for more information on destributed development workflows).

-Neil