Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Date: Mon, 18 Apr 2016 10:40:53 +0200
From: Stefan Sperling <stsp@elego.de>
To: Branko =?utf-8?B?xIxpYmVq?= <brane@apache.org>
Cc: dev@subversion.apache.org
Subject: Re: Deprecation of svn_client_resolve() leaves loose ends
Message-ID: <20160418084053.GG11176@ted.stsp.name>
Mail-Followup-To: Branko =?utf-8?B?xIxpYmVq?= <brane@apache.org>,
	dev@subversion.apache.org
References: <5713BE27.20402@apache.org>
 <20160418082842.GF11176@ted.stsp.name>
 <57149BE7.2090809@apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <57149BE7.2090809@apache.org>
User-Agent: Mutt/1.5.24 (2015-08-30)

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?

Index: subversion/include/svn_client.h
===================================================================
--- subversion/include/svn_client.h	(revision 1739704)
+++ subversion/include/svn_client.h	(working copy)
@@ -4977,12 +4977,13 @@ svn_client_resolved(const char *path,
  * Note that this operation will try to lock the parent directory of
  * @a path in order to be able to resolve tree-conflicts on @a path.
  *
+ * 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.
+ *
  * @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,