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 suggest we keep svn_client_resolve() on the books and just point API users to the more specialised variants in the docs. -- Brane P.S.: It would also be nice if developers compiled stuff in maintainer mode and fixed new warnings before committing ... just sayin'.