Re: Best Practices enquiry

[Paul Sander]

Have you considered a variation on method 1?  Consider this:

Before beginning work on a bug fix, apply a tag to the affected files.  (You
can tag everything in the containing directory if it's easier).  Then fix
the bug.  Then merge the bug fix to the trunk, using the tag as the common
ancestor.

The tag goes fast because its scope is small.  The number of conflicts is
small because they affect only those lines affected by the bug fix.

The bad part is that you need to know in advance what you're going to
change in persuit of the bug fix, so that it can be tagged.  And the
tags will proliferate, but they can be discarded at some point.

--- Forwarded mail from address@hidden

   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.

   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

   2- Merge the branch to the trunk not very often, when the number
      of fixes is sufficiently high to warrant the 3 days that will
      be needed to resolve the conflicts and make sure the fixes
      are still relevant, and use tags to mark the merge points; or

   3- Do not merge at all and manually apply the patch on both
      branches.

--- End of forwarded message from address@hidden