> From: Paul Burba [mailto:ptbu...@gmail.com] Sent: Tuesday, June 29, 2010 > 5:55 PM > On Tue, Jun 29, 2010 at 11:42 AM, C. Michael Pilato <cmpil...@collab.net> > wrote: > > On 06/29/2010 10:36 AM, C. Michael Pilato wrote: > >> I don't believe we support --reintegrate on a two-URL merge. > >> Unfortunately, > >> the client doesn't tell you that -- it just silently falls into a > >> non-reintegrate merge codepath. > > > > I've added a check for this condition in r959004. Will propose for backport > > to 1.6.x, too. > > > > Just to be clear, Servatius, we don't support the use of the --reintegrate > > option with 2-URL merges. You've managed to point out (perhaps > > inadvertantly) that our client doesn't complain when you try to do that, > > though, so that's what I've fixed here. You might want to talk through > > (over on our users@ list) whatever scenario led you to attempt this type of > > merge: what situation merits it, what you expected to happen, etc. > > Agreed, the use case here is legit: Changes on a feature branch need > to make their way to a release branch. I'm simply opposed to having > --reintegrate play a part here (plus I'm grumpy from merge > overexposure :-) > > Paul
Actually, I was just guessing there might be two simple solutions to address this problem, either opening the --reintegrate code for the case where the target WC does not belong to the left-URL or reject the option, what you now will be doing (as the first solution is not simple at all). I do consider this an improvement, because this prevents users from spending time in experimenting with --reintegrate and the 2-URL merge, trying to understand what it really does. I will address my use case with some best practices: always use a full/clean/updated target WC, always ensure that all catch-up merges from the trunk to the feature branch build a single-range mergeinfo, starting at the branch start revision, and explicitly specify the end revision of that range with the trunk URL argument of the 2-URL merge. Thanks, Servatius
