Re: Locks on the Bzr repository

[Stephen J. Turnbull]

Lluís writes:

 > If a bug is fixed on the release branch (emacs-23) using branch
 > merges, so that the history of emacs-23 will read "fix bug N", how
 > can the same history clarity be maintained in trunk?

See my previous reply for a brief discussion.

 > I mean, both the emacs-23 branch and trunk would like to benefit
 > from fixing those bugs, but if the release branch is merged into
 > trunk,

No, you essentially never want to do that.  The trunk will diverge
quickly from the release branch.  It has better (but risky) fixes for
some bugs, new features requiring changed APIs, etc.  However, some
changes to the release branch will depend on the old code, and trying
to merge that into the trunk will create One Big Mess.  (This is what
"merge branches" *means*: *all* of the code needs to be merged, not
just the "good" code you want.)

 > the nice messages from emacs-23 are lost once merged into
 > trunk, right?

I don't understand what you mean by "losing the messages".  The
messages are part of the commit object, and come with it in a merge.

 > And merging the new feature/fix branch into both emacs-23 and trunk
 > would provide the desired history structure outcome, but this is
 > kind of troublesome as the merge operation must be performed
 > twice...

This is true, anyway.  The nature of branches is that they diverge,
and the changes that are appropriate diverge, too.

 > I imagine this is exactly the place where rebase makes sense (merge
 > new branch into emacs-23, then rebase emacs-23 into trunk),

Actually, most projects do this in the opposite direction.  Features
and fixes go into trunk, first, typically at developer discretion.
Then the release manager picks ("cherry-picks") the bug fixes
appropriate from the release branch.