Re: Locks on the Bzr repository

[Lluís <xscript@gmx.net>]

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?

And now that I think of it. Suppose the case (like emacs) of having a main
development branch where new features and bug fixes as merged, and branches for
tagging minor releases as bugs are fixed on each major version (i.e.,
emacs-23).

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? 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,
the nice messages from emacs-23 are lost once merged into trunk, right? 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... I imagine this is exactly the place
where rebase makes sense (merge new branch into emacs-23, then rebase emacs-23
into trunk), but this should in fact be an operation that is performed only by a
small set of developers.

Am I missing something? Or is this precisely the workflow emacs is supposed to
use?

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