Branko Čibej <br...@wandisco.com> writes: > My main objection to this approach is that it breaks all the API > patterns we've ever had: it creates a function that does not return an > error even though it clearly fails, and relies on some notification > callback to report actual errors.
We have been reporting errors via callbacks since 1.2, look at svn_ra_lock(). We have done it again in 1.9, look at svn_fs_lock_many(). Also, is the function clearly failing when it reports a verification error? If it is correctly diagnosing that the repository is corrupt then the function is in some sense succeeding. I suppose we could change svn_repos_notify_t.err to some other type, but svn_error_t is a convenient way to package the information. -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
