[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: Fri, 3 Aug 2012 22:12:10 +0100 (BST)

Mark Phippard wrote:

> On Fri, Aug 3, 2012 at 4:54 PM, Julian Foad wrote:
>> Today, if the user gives the --reintegrate option when a
>> non-reintegrate merge is the appropriate one based on past
>> merges, Subversion goes through the motions of a reintegrate
>> merge and produces the wrong result.  [...]
>
> If it does the wrong thing today in this situation, then I am in favor
> of your proposal.
>
>>> Do you plan on adding a new mergeSync API to JavaHL or just have the
>>> JavaHL C++ code call the new API when the RevisionRange is passed as I
>>> noted above?  I would be fine with the latter as I do not think it
>>> introduces any unexpected new behaviors.  There is already a specific
>>> mergeReintegrate JavaHL API.
>>
>> I would prefer to add a new API to JavaHL, as the current merge
>> API is already way too overloaded with variations of behaviour in
>> my opinion.
>
> That is OK with me.  Based on the existing signature I mentioned, it
> seems like the only option you would drop is the RevisionRange
> argument.  I think when Hyrum cleaned up the JavaHL methods he just
> preferred to not have as many subtle variants of the method.
>
> Regardless which option you choose, I just wanted to be sure there was
> some way we can use the new API from JavaHL.  Adjusting Subclipse to
> use the right method will be trivial.
>
> A couple of other comments:
>
> You do not mention explicit 2-URL merges but I assume those will be unchanged?

Correct: 2-URL merges are unchanged.

> You do not mention foreign repository merges.  Perhaps the wiki does?

They are non-merge-tracking merges, and so should be unchanged.  I will check whether that's correctly implemented.

- Julian
Received on 2012-08-03 23:12:46 CEST

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