RE: Best Practices enquiry

[Jim.Hyslop]

Yannick Fortin wrote:
>    We currently have a rather standard setup. We have a 
> branch for the 
> stable, released version of our software where we only put 
> bug fixes and 
> minor improvements. All the development is made on the trunk (or 
> short-lived branches as needed). We are a few days away from 
> releasing a 
> new version. After this release, we intend to switch the bulk of the 
> work to the trunk.
Wait a minute - I thought you just said the branch only contains bug fixes
and minor improvements - why are you switching "the bulk of the work" to the
trunk? Most of your work should *already* be on the trunk.

>    Obviously, we want the bug fixes made on the stable branch 
> to also be 
> included in the trunk, but not the other way around. How should we 
> proceed ? I see 3 alternatives. Either
> 
>    1- Merge the branch to the trunk each time a bug fix is done on
>       the branch, resolving (an increasing number of) conflicts
>       as they appear (no real need for merge tags in this case); or
Merge-as-you-go is the best approach. It minimizes conflicts. Remember, when
you merge, you don't merge from the base of the branch to the tip, only from
the previous revision to the one you just checked in.

>    3- Do not merge at all and manually apply the patch on both
>       branches.
This is still merging, it's just a manual merge instead of an automated
merge. This is what I do if the changes are trivial.

-- 
Jim Hyslop 
Senior Software Designer 
Leitch Technology International Inc. (<http://www.leitch.com/>) 
Columnist, C/C++ Users Journal (<http://www.cuj.com/experts>)