Re: Fold the merge_automatic API into the existing merge_peg API

Branko Čibej wrote:

> On 28.03.2013 22:07, Julian Foad wrote:
>> Branko Čibej wrote:
>>> On 28.03.2013 21:38, Julian Foad wrote:
>>>> I like the focused API, but I also see how the automatic merge can be
>>>> considered to fill in a bit of missing functionality that merge_peg
>>>> ought to provide.
[...]
>>> I like it. Apparently the encapsulation is even simpler than I expected.
>>
>> Heads up: that patch is broken.  merge_automatic_tests.py 7 though 14 all
>> fail.  However, it's most likely broken in a rather trivial way so I expect
>> the corrected version will still be simple.

It was indeed a simple goof.

>>> For JavaHL, a simple overload of ISVNClient.merge can provide the
>>> "focused" interface without inventing yet another type of merge API.
>>> Even better, passing null for the revision ranges in the existing
>>> merge-peg overload can be made to yield the same effect, without
>>> affecting the API signature at all. (Currently IIUC passing a null
>>> ranges array will cause an error.)
>>
>> Making the C API accept NULL for the revision-ranges array argument
>> would be a totally sensible extension.  I'll do that.
>
> I was thinking of the JavaHL API, but you're right -- the C API could
> benefit from the same simplification.

OK, I've got that working and I'm happy with it.  Committed in 1463250.  Any further review or changes can come later.

TODO: Decide whether to keep or make private or delete the dedicated 'automatic merge' APIs.

This reduces the verbosity of 'svn merge --verbose' for an automatic merge.  We can consider putting some verbosity back in in another way.  One option is to add some new notifications for the notifier callback, although I don't like that.  I don't think this is important, so will leave it as it is unless we come up with a good suggestion.

- Julian
Received on 2013-04-01 21:04:07 CEST