Re: Locks on the Bzr repository

[Lluís]

Stephen J Turnbull writes:

> 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.)

Ah, you're right.


>> 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.

I meant that, for example, you merge in a branch for a bugfix into the stable
branch. The log in stable will say something like "fix bug N", although this
might be composed of various commits. Then, you merge stable into trunk, but
merging will no longer show "fix bug N" on the leftmost part of the history in
bazaar, so any changes in stable from last merge into trunk will all be "hidden"
under a single "merge from stable", instead of having now a history on trunk
that shows what exactly has modified in stable and merged into trunk.

Of course, this will not happen with a merge from release into trunk (for the
reasons you explained), but still can happen for any other set of 3 or more
branches; as long as the branch "relation chain" is shorter than 3 levels,
everything's OK, but that's essentially a flat model where every feature/fix is
on its own branch (which is never a release nor a trunk branch) and those
feature/fix branches must be merged multiple times, one into each release/trunk
branch where you want to see that change.

This approach can produce exceptionally nice history logs (in the sense that bzr
hides history messages "inside" a merge), but it seems to me that at the expense
of a higher managing effort.

Of course that effor might already be there on any other approach/workflow, it's
just that this is my first encounter with DVCS.


>> 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.

Then you're in favour of the "flat" model I described above.


>> 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.

Completely right, because of what you pointed out on your second paragraph.


Lluis

-- 
 "And it's much the same thing with knowledge, for whenever you learn
 something new, the whole world becomes that much richer."
 -- The Princess of Pure Reason, as told by Norton Juster in The Phantom
 Tollbooth