[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Best Practices enquiry
From: |
Paul Sander |
Subject: |
Re: Best Practices enquiry |
Date: |
Wed, 4 Feb 2004 13:39:38 -0800 |
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