[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Deprecation of svn_client_resolve() leaves loose ends

From: Branko Čibej <brane_at_apache.org>
Date: Mon, 18 Apr 2016 10:33:43 +0200

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.