On Wed, May 16, 2012 at 01:57:45PM +0200, Stephen Butler wrote:
> I'd recommend doing cherrypicking merges from B to T.
I believe either of Asher's or Steven's suggestion would work fine.
If you go for the cherry-pick from B to T option, you might want to
block the resulting commits to T from being merged to B by performing
a --record-only merge of those revisions to B. Then, fully sync B back
up with T, and during that merge you shouldn't see much spurious conflicts,
if any. Now keep syncing B to T regurlarly, and finally --reintegrate B
at a later time.
The most important point to consider though is how you ended up in this mess
in the first place. Somehow you ended up with a branch B that doesn't
contain a clean changeset. That is the real problem. You would pretty
much have to use cherry-picking in any version control system at this
point, so your question is not particularly specific to Subversion's merge.
Obviously, there was some bad planning, or inconsiderate changes were
made to B. You should investigate how this happened and try to prevent
this problem from happening again (by educating developers, more careful
planning, drinking more coffee, or whatever else will help).
Oh, and Steve's suggestion to try out merge scenarios is a good one.
Please don't take our word for it but try out various approaches in
a test environment before you apply them in production.
Good luck!
Received on 2012-05-16 14:13:19 CEST