Re: Locks on the Bzr repository

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

Lluís <xscript@gmx.net> 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?

In Bazaar, it is fine to continue adding to a branch after it has been
merged once.  Next time it is merged, Bazaar can figure out which
revisions are new and merge them appropriately.

> Now that I think of it, I think I start to see the reason for nested
> history and the suggestion of not using rebase. Even for the
> smallest bug fix or feature addition, a full branch should be
> created, and every change should be thoroughly tested in
> there. Then, trunk would be composed of just merge messages like
> "add subsystem Y", "add feature X to subsystem Y", "fix bug N on
> Y". This would produce a log in trunk that would very closely
> resemble the contents of a NEWS file, but at the expense of a strict
> branch/test/merge discipline, which is not bad per-se.

There is no harm in creating task branches for individual bug fixes.
But, that in itself doesn't make one virtuous.  The crucial testing to
be done is *after you merge it into trunk*.  Testing in the task
branch is not enough.  Every time you do pull/update/merge, you need
to test again.  

The workflow recommended for "Quick Fixes" in the Wiki has no logical
problem, even though it avoids task branches.  Its only problem is
that it is slow, especially when used with an sftp server.

Cheers,
Uday