[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Shouldn't --reintegrate used with a 2-URL merge perform checks?

From: Brandt, Servatius (External) <servatius.brandt.external_at_ts.fujitsu.com>
Date: Wed, 30 Jun 2010 14:25:55 +0200

> 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.


Received on 2010-06-30 14:26:43 CEST

This is an archived mail posted to the Subversion Dev mailing list.