Re: Locks on the Bzr repository

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

Uday S Reddy writes:

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

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


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

See above. But basically, we agree as long as you merge on each fix.

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.


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