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
