subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Evgeny Kotkov <>
Subject 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/
Date Fri, 26 Jun 2015 14:44:56 GMT
Ivan Zhakov <> 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.


Evgeny Kotkov

View raw message