Re: Locks on the Bzr repository

["Stephen J. Turnbull" <stephen@xemacs.org>]

Lluís writes:

 > Just to make sure I understand it. Suppose I'm working on a branch
 > with a fairly large set of changes and it has been merged back to
 > trunk. After a while a bug is found on my code, which was not
 > thoroughly tested, or a new relatively minor functionality is added
 > related to the code on my branch. Should this be committed on my
 > branch and then followed with a merge to trunk? Or should this live
 > in a completely new branch that will be merged back to trunk once
 > it's well tested?

I think it's a matter of taste.  After the first merge to trunk, you
have this history:

0 -- T1 -- ... -- Tn -- 1
 \                     /
  B1 --    ...    -- Bm

You can close the original branch, and create a new one, giving this
history:

0 -- T1 -- ... -- Tn -- 1 -- ... -- Tp -- ... -- Tq -- 2
 \                     /              \               /
  B1 --    ...    -- Bm                `---------- Fix

or you can continue on your branch


0 -- T1 -- ... -- Tn -- 1 -- ... -- Tp -- ... -- Tq -- 2
 \                     /                              /
  B1 --    ...    -- Bm -------------------------- Fix

with very similar effect (bzr knows that B1 ... Bm are already in Tq,
so it will apply effectively apply the patch (Bm -> Fix) to Tq).  The
main difference is that you could have a conflict between Fix and some
patch between 1 and Tp in the "continued feature branch" case, but you
would take the changed code into account in producing Fix for the
"make new branch for fix" case.  In the common case that nobody
touches "your" code between 1 and Tq, these are 100% equivalent.

The other issue is workflow.  If the workflow is like Launchpad or
github, where release managers pull in whole branches from
contributors, it may make sense to use the "continued feature branch"
approach.  Then both "stable" and "devel" branches can pull from your
feature branch, without polluting each other.

In a workflow like Emacs's, where contributions go to trunk and
release manager looks for patches to cherry-pick, the "branch per fix"
approach probably makes more sense.

 > Now that I think of it, I think I start to see the reason for
 > nested history and the suggestion of not using rebase. Even for the
 > smallest bug fix or feature addition, a full branch should be
 > created, and every change should be thoroughly tested in
 > there.

Thoroughly tested, yes, but remember, it is never possible to fully
test in a feature branch (unless the feature branch is the first
continuation applied to the tip of the trunk it branched from).

 > Then, trunk would be composed of just merge messages like "add
 > subsystem Y", "add feature X to subsystem Y", "fix bug N on
 > Y". This would produce a log in trunk that would very closely
 > resemble the contents of a NEWS file, but at the expense of a
 > strict branch/test/merge discipline, which is not bad per-se.

I believe that's very much the way the Bazaar developers think of it.