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!
