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