> From: Paul Burba [mailto:ptburba_at_gmail.com] Sent: Tuesday, June 29, 2010 5:55 PM
> On Tue, Jun 29, 2010 at 11:42 AM, C. Michael Pilato <cmpilato_at_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
Received on 2010-06-30 14:26:43 CEST