On 26 June 2015 at 17:44, Evgeny Kotkov <evgeny.kot...@visualsvn.com> wrote: > Ivan Zhakov <i...@visualsvn.com> writes: > >>> +/** Callback type for use with svn_repos_verify_fs3(). @a revision >>> + * and @a verify_err are the details of a single verification failure >>> + * that occurred during the svn_repos_verify_fs3() call. @a baton is >>> + * the same baton given to svn_repos_verify_fs3(). @a scratch_pool is >>> + * provided for the convenience of the implementor, who should not >>> + * expect it to live longer than a single callback call. >>> + * >> Who is responsible for clearing verify_err: caller or callback implementor? > > That is the caller's responsibility. I documented this in the docstring > that precedes the svn_repos_verify_fs3() declaration ... > > + * failure. Set @c revision callback argument to #SVN_INVALID_REVNUM or > + * to the revision number respectively. Set @c verify_err to svn_error_t > + * describing the reason of the failure. @c verify_err will be cleared > + * after the callback returns, use svn_error_dup() to preserve the error. > > ...but now I think that it makes sense to say this again in the documentation > for svn_repos_verify_callback_t. So, I committed that in r1687776 [1]. > > Anticipating further possible questions, I chose the approach where a calling > site of the callback is responsible for clearing the error because I think > that the reverse design would be rather painful for potential implementors, > including ourselves. The callback can potentially return (other) errors while > processing the verification error, hence transferring the verify_err lifetime > to the callback would require a bigger amount of efforts — just to avoid an > error leak. We also have svn_fs_lock_callback_t that sticks to the same > approach, and I chose not to come up with something new here. > > [1] https://svn.apache.org/r1687776 > OK, makes sense. Thanks for explanation and docstring clarification!
-- Ivan Zhakov
