OK, enabled in 1369896.
--reintegrate forces a 1.7 reintegrate, unconditionally, at the moment; I haven't put a deprecation warning in there.
Please let me know if anyone sees unexpected results from merge now.
TODO:
* Revise 'svn merge' help text.
* Checks for 'no local mods' and 'no switched subtrees' aren't currently being performed when they should; it needs to wait till after working out which kind of merge is required, and then do the strict checks iff it's reintegrate-like.
* Check foreign-repos merges don't try to use the symmetric merge code path.
* Add a JavaHL API version of svn_client_merge_symmetric().
* ambiguity: reintegrate or not (merge_symmetric_tests-18)
Email thread "Symmetric merge and subtrees".
* Issue #4217 -- reported rev unexpected (merge_tests-78)
Email thread "Symmetric merge and deleted subtrees".
- Julian
----- Original Message -----
> From: Julian Foad <julianfoad_at_btopenworld.com>
> To: Branko Čibej <brane_at_wandisco.com>
> Cc: "dev_at_subversion.apache.org" <dev_at_subversion.apache.org>
> Sent: Monday, 6 August 2012, 10:23
> Subject: Re: Enabling symmetric merge, and UI details
>
> 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 20:09:46 CEST