Re: Locks on the Bzr repository

["Óscar Fuentes" <ofv@wanadoo.es>]

Lluís <xscript@gmx.net> writes:

[snip]

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

To see them you'll need the -n0 switch, yes. This is an important case
that breaks the "niceness" of having a privileged arm on the DAG.

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

Rebasing has the undesirable effect of changing the identity of the
commits, so it is no longer possible to easily test the presence of one
change on several branches ("is commit 388743FA2 present in this
branch?") This is another reason for never rebasing commits that were
released to the public. So no, I don't think that `rebase' would be the
right tool for keeping a nice bzr log on the emacs-23/trunk exchange of
commits.

[snip]