subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko ─îibej <br...@apache.org>
Subject Re: Deprecation of svn_client_resolve() leaves loose ends
Date Mon, 18 Apr 2016 08:33:43 GMT
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


Mime
View raw message