On Fri, Aug 3, 2012 at 4:54 PM, Julian Foad <julianfoad_at_btopenworld.com> wrote:
>> 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?
>
> 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. (Wrong in the
> sense that it doesn't properly merge the sets of unique changes from the two branches, not that it doesn't do
> exactly what we taught it to do.)
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?
You do not mention foreign repository merges. Perhaps the wiki does?
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2012-08-03 23:00:46 CEST