Bazaar User Guide: Workflows

[Ian Clatworthy]

Eugene Wee wrote:
> Hi,
> 
> In the Bazaar User Guide section 1.3.6 (Decentralized with shared
> mainline [1]) I noticed that the text reads:
> 
> "In this workflow, each developer has their own branch or branches, plus
> commit rights to the main branch. They do their work in their personal
> branch, then merge it into the mainline when it is ready."
> 
> The graphical illustration then has "bzr branch" for step 1, "bzr pull"
> and "bzr merge" for step 2, and "bzr commit" for step 3. It seems to me
> that "commit rights" is used rather loosely, since step 3 should
> actually be "bzr push". Perhaps the graphical illustration should be
> changed to mention "bzr push" instead?

Eugene,

Sorry for the very late reply to this.

I agree that the diagram needs to be clearer and that the description is
far too loose.

I really do mean "commit" though, not "push". To dig a hole for myself
though, that 'commit' might happen by one of several ways including a
push of a merge commit. Another way, and perhaps the one I ought to be
recommending (?), is to commit to a checkout of the shared mainline.

The key point is that the work, and incremental commits, are done in a
separate branch. When ready, that work is then merged+committed to the
shared mainline. Here's a concrete example ...

A project's tip is revision 100. A developer branches from it to make
changes. He makes 4 commits in his local branch. When ready, he merges
his changes into a checkout and commits.

Assuming no one else has committed anything, running 'bzr revno' on the
shared mainline shows 101. In comparison, if 'push' had been run
directly from the work branch instead of a merge+commmit, 'bzr revno'
would show 104.

The difference mightn't seem a big deal to some but it is IMNSHO. If all
developers simply push from work branches, then the mainline ends up
looking just like a traditional CVS/SVN one - heaps of uninteresting
(from the global perspective) commits with occasion ones representing a
known good state. By merging and committing as suggested, the mainline
is meaningful, bzr log --short is useful for viewing the big picture, an
item of work can be easily backed out if required and continuous
integration tools can trigger off mainline (only) changes.

Does that make sense?

Ian C.