subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan Zhakov <i...@visualsvn.com>
Subject Re: Possible incompatibility of svn_repos_verify_fs2() in 1.9.0-rc1
Date Wed, 03 Jun 2015 17:38:14 GMT
On 3 June 2015 at 20:29, Branko ─îibej <brane@wandisco.com> wrote:
> On 03.06.2015 17:10, Ivan Zhakov wrote:
>> On 3 June 2015 at 17:19, Branko ─îibej <brane@wandisco.com> wrote:
>>> On 03.06.2015 15:31, Ivan Zhakov wrote:
>
>>>>  I'm also not sure that we have to return error if we already reported it
via notify_func in
>>>> svn_repos_verify_fs3().
>>>
>>> Out notification mechanism cannot replace API consistency. When an API call
>>> fails, it must return an svn_error_t; surely you're not proposing that we
>>> make an exception for svn_repos_verify_fs3?
>>>
>> This is depends whether check of corrupted repository is error or not.
>> I mean that semantic could be: "please give me all/first corruptions
>> in this repository via notify_func".
>
> Hm, well, that would be a different API than what svn_repos_verify_fs3
> documents.
>
Of course docstring should be updated in this case. My point was that
we could define svn_repos_verify_fs3() API to report repository
corruptions only via notify_func because these errors are special.

> An API user who wants an early exit can always trigger the cancel_func
> in her notification handler and get SVN_ERR_CANCELLED in response.
>
The problem that it's could be hard to distinguish summary errors from
repository corruption errors itself for API user.

-- 
Ivan Zhakov

Mime
View raw message