[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r1687769 - in /subversion/trunk/subversion: bindings/javahl/native/ bindings/javahl/src/org/apache/subversion/javahl/ include/ libsvn_repos/ svnadmin/ tests/cmdline/ tests/libsvn_fs_fs/

From: Ivan Zhakov <ivan_at_visualsvn.com>
Date: Fri, 26 Jun 2015 17:56:24 +0300

On 26 June 2015 at 17:44, Evgeny Kotkov <evgeny.kotkov_at_visualsvn.com> wrote:
> Ivan Zhakov <ivan_at_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
Received on 2015-06-26 16:57:15 CEST

This is an archived mail posted to the Subversion Dev mailing list.