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

Re: Enabling symmetric merge, and UI details

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Mon, 6 Aug 2012 15:23:21 +0100 (BST)

Branko Čibej wrote on 3 August 2012:

> On 03.08.2012 21:51, Mark Phippard wrote:
>> On Fri, Aug 3, 2012 at 3:25 PM, Julian Foad wrote:
>>>   * Make the '--reintegrate' option mean the user believes
>>>     a reintegrate-style merge is needed, so check that the
>>>     previous merge is as expected (that it, in the opposite
>>>     direction) and bail out if not.
>>
>> Why do you want to do this?  Just to educate the user that they do not
>> need reintegrate?  It does not seem like it would be necessary.  What
>> happens today if the user does this?  I guess if --reintegrate does
>> the wrong thing today then this makes sense.  But if it basically
>> still gives a valid result why bother to make a behavior change in
>> what is a deprecated option anyway?
>
> I concur. Our goal is to make the merge algorithm truly symmetric within
> the next release or two, inshallah. In order to get there, the behaviour
> of "svn merge" will certainly change in some scenarios, but we obviously
> expect that the results will become more correct. As long as we can
> argue that any such changes in 1.8 are simply incremental adjustments on
> the way towards that goal, it seems a waste of effort to maintain any
> kind of special meaning for the --reintegrate option.
>
> IMO the only thing --reintegrate should do in 1.8 is to issue a warning
> about it being deprecated; and in 1.9 it we can silently ignore it.

You mean --reintegrate should cause 'svn' to do a 1.7 reintegrate merge (and issue a deprecation warning)?  I don't have an opinion on the warning, but doing an old-style reintegrate makes sense: there is no need to make the behaviour of that option more complex like I was suggesting.

- Julian
Received on 2012-08-06 16:23:58 CEST

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