Re: Locks on the Bzr repository

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

Stephen J Turnbull writes:

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

> I think it's a matter of taste.  After the first merge to trunk, you
> have this history:

> 0 -- T1 -- ... -- Tn -- 1
>  \                     /
>   B1 --    ...    -- Bm

> You can close the original branch, and create a new one, giving this
> history:

> 0 -- T1 -- ... -- Tn -- 1 -- ... -- Tp -- ... -- Tq -- 2
>  \                     /              \               /
>   B1 --    ...    -- Bm                `---------- Fix

> or you can continue on your branch


> 0 -- T1 -- ... -- Tn -- 1 -- ... -- Tp -- ... -- Tq -- 2
>  \                     /                              /
>   B1 --    ...    -- Bm -------------------------- Fix

Which basically means your history will look like:

0
T1
...
Tn
1: merge feature B
...
Tp
...
Tq
2: fix bug on feature B

no matter which of both approaches you take.

Even more, one should not expect that a feature branch will be indefinitely
available for committing new changes into it; which means that at some point in
time, the branch will have disappeared (been deleted by its creator) and fixes
for such feature will be merged from some other sources.

That is to say that the approach of multiple branches for a single feature is
more likely to happen on projects spanning an arbitrarily large amount of time.


[...]
> The other issue is workflow.  If the workflow is like Launchpad or
> github, where release managers pull in whole branches from
> contributors, it may make sense to use the "continued feature branch"
> approach.  Then both "stable" and "devel" branches can pull from your
> feature branch, without polluting each other.

Which would solve my question about how the same fix in multiple branches could
be shown nicely in the history, but at the expense of having to merge twice,
and having to type twice the same merge message ("merge fix for bug N" or
whatever) if you still want a "coherent" history log between branches.


> In a workflow like Emacs's, where contributions go to trunk and
> release manager looks for patches to cherry-pick, the "branch per fix"
> approach probably makes more sense.

Well, the only difference I see is that on the Emacs' workflow it is supposed
that developers have less means to publish their own branches, so release
managers cherry-pick commits from trunk instead of merging developer's branches
into both trunk and stable.

And I suppose the reason for such approach is to minimize the amount of work
that developers require to work with bazaar instead of CVS.


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