Jon H wrote:
> the way we manage our development is so that all work is done in
> branches. Limited to 1 new feature or 1~6 fixes (depending on
> size/scope) per branch.
> Now lets say I merge in a branch that has 6 fixes in it, into our
> Main(trunk). if it is decided to back out 1 of those features the
> only I know how is to remove all the features that came with it, and
> then resurrect the branch they came from.. remove the feature from
> that and then re-merge the remaining features..
> to avoid doing this I wonder, is it possible to generate a patch file
> form the parent branch and generate a patch of the work done for a
> fix, and then apply it to the main development in reverse? so it
> REMOVES what the patch matches rather than adds?
> suggestions/answers on a postcard!
Nice try Jon, by no means this is an easy one.
Yes, you _could_ generate that patch which removes the unwanted feature.
But does this reflect the way you work? I wonder.
If the bad feature made it into the "stable" Main code line in the first
place, does that not indicate a problem with QA in the pre-integration
code line? This is where the correction needs to take place. Add a
failing test, then fix it by removing the "bad" feature.
I think your initial idea of backing out the whole integration and
starting over does have its merits.
Another approach would be to fix the issue after integration, _no matter
what_. This would place the burden on the whole team. You allow someone
to integrate stuff, everyone is responsible it works.
Michael Diers, elego Software Solutions GmbH, http://www.elego.de
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-10-09 22:41:07 CEST