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
