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

Re: Possible incompatibility of svn_repos_verify_fs2() in 1.9.0-rc1

From: Ivan Zhakov <ivan_at_visualsvn.com>
Date: Wed, 3 Jun 2015 20:38:14 +0300

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

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