> -----Original Message-----
> From: Stefan Sperling [mailto:stsp_at_elego.de]
> Sent: Wednesday, May 16, 2012 5:13 AM
> To: Stephen Butler
> Cc: Asher Stern; users_at_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
Received on 2012-05-16 18:17:09 CEST