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