On 18.04.2016 10:28, Stefan Sperling wrote:
> On Sun, Apr 17, 2016 at 06:47:35PM +0200, Branko Čibej wrote:
>> I've been looking at and fixing new compile-time warnings on trunk, and
>> noticed that the svn_client_resolve() function was deprecated in
>> r1730495 in favour of three new functions that are specialised for text,
>> property or tree conflict resolution.
>>
>> This change causes a deprecation warning to be emitted in
>> svn_cl__resolved(); and I'm fairly sure we shouldn't be calling
>> deprecated functions in the command-line client. (The warning probably
>> gets emitted from JavaHL too, but I haven't checked that.)
>>
>> This causes me to wonder if deprecating svn_client_resolve() is really
>> such a good idea. It forces API users to jump through hoops to discover
>> the conflict type(s) and then calling up to three functions to mark the
>> conflict(s) resolved instead of just one; effectively changing a
>> one-liner to an unwieldy bunch of code.
> I agree that, for non-interactive clients, calling 'svn_client_resolve()'
> is easier. Also, the new API has no equivalent for the 'depth' parameter of
> svn_client_resolve().
I find this just a bit confusing ... How can typing "svn resolved -R' at
the command prompt be considered non-interactive?
-- Brane
Received on 2016-04-18 10:33:27 CEST