[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 19:09:11 +0100 (BST)

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

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