Re: Locks on the Bzr repository

[Uday S Reddy <U.S.Reddy@cs.bham.ac.uk>]

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

> Sure, my only concern is on how the history will look like. Suppose
> I have commits (f1, f2, f3) implemeting some feature. These are
> merged into trunk as revision f. Then I fix a simple bug on the
> feature (ff11) and merge again as ff1. Fix another bug with multiple
> commits (ff21, ff22) and fix another one with a single commit
> (ff31). If now I merge, both fixes are merged into trunk, and
> supposing they are independent from each other, ideally they should
> appear as two different entries on the history in trunk (ff2 and
> ff3).

If you want ff2 and ff3 to appear as separate merges in the history,
then you merge them separately.  But they can all sit in the same
feature branch at your end.

In my context, I often want to review the contributions that our
people send in (via Bazaar branches on Launchpad).  There I prefer if
they do all their work of a particular feature in a single branch.
Then I can just pull it into my local copy, review it and merge it in.
If they make a new branch for each fix, it will add additional set-up
cost for me to make a copy of their branch.

I might also mention that it was in this context that I first used
rebase.  Since the contributions are often based on some old revision
in the trunk, which is a pain to go back to, I first rebase my copy of
their branch to the current state of the trunk.  Then I review and
test each commit, before merging it in.  I think this is a great
application of rebase.  Not only is it safe (because rebase is done
before review), it is a lot better than merge which will just plonk
everything together and hope for the best!

> Of course, this is all to, at the end, have a history in trunk that
> is shown as: ... f ... ff1 .... ff2 .... ff3 ...
>
> so that history quickly shows at a high level what has been changed just by
> looking at the "first level" of the history.

Sounds perfect!

Cheers,
Uday