[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: Stefan Sperling <stsp_at_elego.de>
Date: Mon, 18 Apr 2016 10:44:22 +0200

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,
Received on 2016-04-18 10:44:30 CEST

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