[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:48:08 +0200

On 18.04.2016 10:44, Stefan Sperling wrote:
> On Mon, Apr 18, 2016 at 10:40:53AM +0200, Stefan Sperling wrote:
>> On Mon, Apr 18, 2016 at 10:33:43AM +0200, Branko Čibej wrote:
>>> 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?
>> How about this, then?
> I think I've found an even better place to put this information:
>
> Index: subversion/include/svn_client.h
> ===================================================================
> --- subversion/include/svn_client.h (revision 1739704)
> +++ subversion/include/svn_client.h (working copy)
> @@ -4956,7 +4956,11 @@ svn_client_resolved(const char *path,
> * - svn_wc_conflict_choose_unspecified
> * invoke @a ctx->conflict_func2 with @a ctx->conflict_baton2 to obtain
> * a resolution decision for each conflict. This can be used to
> - * implement interactive conflict resolution.
> + * implement interactive conflict resolution but is NOT RECOMMENDED for
> + * new code. To perform conflict resolution based on interactive user
> + * input on a per-conflict basis, use svn_client_conflict_text_resolve(),
> + * svn_client_conflict_prop_resolve(), and
> + * svn_client_conflict_tree_resolve() instead of svn_client_resolve().
> *
> * #svn_wc_conflict_choose_theirs_conflict and
> * #svn_wc_conflict_choose_mine_conflict are not legal for binary
> @@ -4978,11 +4982,7 @@ svn_client_resolved(const char *path,
> * @a path in order to be able to resolve tree-conflicts on @a path.
> *
> * @since New in 1.5.
> - * @deprecated Provided for backward compatibility with the 1.9 API.
> - * Use svn_client_conflict_text_resolve() , svn_client_conflict_prop_resolve(),
> - * and svn_client_conflict_tree_resolve() instead.
> */
> -SVN_DEPRECATED
> svn_error_t *
> svn_client_resolve(const char *path,
> svn_depth_t depth,

Looks good, +1.

-- Brane
Received on 2016-04-18 11:05:14 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.