Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm
Precedence: bulk
MIME-Version: 1.0
In-Reply-To: <556F3CF8.3030001@wandisco.com>
References: 
 <CAP_GPNgAz4LUmijrLD2pSj_Z=mj6VvZPOSZiyvzqLXNmjOAxfg@mail.gmail.com>
 <556EF413.6060303@wandisco.com>
 <CABw-3YfL5kt3FgbBb039GP8av+CvjPX5O6=hHXTNFY6bx+aAKg@mail.gmail.com>
 <556F0D04.3020006@wandisco.com>
 <CABw-3YcBnXwgzZXYzDx0-8bZJU976MEMVa2RprWthGh6Jgjv8Q@mail.gmail.com>
 <556F397F.7070709@wandisco.com>
 <CABw-3Yd0ofsrG2F6ejAaA82wkUmue0v6xkVwaOPPuuio65cJdQ@mail.gmail.com>
 <556F3CF8.3030001@wandisco.com>
From: Ivan Zhakov <ivan@visualsvn.com>
Date: Wed, 3 Jun 2015 20:50:43 +0300
Message-ID: 
 <CABw-3YfC=8fD7Q4OKmrgHFr8HtRwxLnOBPHzFPcoyM3rqPpX9Q@mail.gmail.com>
Subject: Re: Possible incompatibility of svn_repos_verify_fs2() in 1.9.0-rc1
To: =?UTF-8?Q?Branko_=C4=8Cibej?= <brane@wandisco.com>
Cc: dev@subversion.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 3 June 2015 at 20:44, Branko =C4=8Cibej <brane@wandisco.com> wrote:
> On 03.06.2015 19:38, Ivan Zhakov wrote:
>> On 3 June 2015 at 20:29, Branko =C4=8Cibej <brane@wandisco.com> wrote:
>>
>>> 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.
>
> Why? The summary error code (SVN_ERR_REPOS_VERIFY_FAILED) is used in
> only at the end of a run with keep_going=3DTRUE iff the FS backend
> returned an error. It cannot be returned from the FS backend validation
> functions, so it will never appear in a notification and will never be
> returned when keep_going=3DFALSE. In fact, that's the main reason I
> decided to keep a separate, new error code for this case.
>
Is it documented that only SVN_ERR_REPOS_VERIFY_FAILED used for
summary errors? Do we promise to always return this error code?

Anyway I didn't say that it's impossible to distinguish them, but
could be complicated and may be we should make it API user
responsibility to construct summary error if needed.

--=20
Ivan Zhakov