> -----Original Message----- > From: Stefan Sperling [mailto:s...@elego.de] > Sent: Wednesday, May 16, 2012 5:13 AM > To: Stephen Butler > Cc: Asher Stern; users@subversion.apache.org > Subject: Re: Merge and record-only question > > 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).
It depends on the scenario. If branch B is not a feature branch per se, there may be valid reasons to not merge back changes. Rather than just use cherry-pick merges, it may be easier to use --record-only to permanently block those changes from being merged. Of course, it is a good idea to put in a good comment on that checkin to remember why the changes are being blocked. But once you do, you can just do a branch to branch merge rather than cherry-pick. > > 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! Agreed. -Steve
