On 3 June 2015 at 20:29, Branko Čibej <brane_at_wandisco.com> wrote:
> On 03.06.2015 17:10, Ivan Zhakov wrote:
>> On 3 June 2015 at 17:19, Branko Čibej <brane_at_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
Received on 2015-06-03 19:38:51 CEST