> -----Original Message-----
> From: 'Daniel Shahaf' [mailto:d.s_at_daniel.shahaf.name]
> Sent: dinsdag 9 juli 2013 18:39
> To: dev_at_subversion.apache.org
> Cc: commits_at_subversion.apache.org
> Subject: Re: svn commit: r1501049 - in /subversion/trunk/subversion:
> include/svn_error_codes.h libsvn_ra_serf/util_error.c
>
> Daniel Shahaf wrote on Tue, Jul 09, 2013 at 16:20:56 +0000:
> > I accept that some API users may depend on
> SVN_ERR_RA_SERF_WRAPPED_ERROR. Do
> > you think it is a problem to assign that new meaning to it in 1.8.x? I
reused
> > it for the same reasons you re-used an existing error code in r1498851,
if
> you
> > think a new error code is needed on trunk I'm happy to add one.
>
> Looking at your comment:
>
> The reason for the -1 is the re-use of a specific error
code
> that is automatically unwrapped in some ra_serf code,
to avoid
> handling codes like APR_EOF as non fatal)
>
> Weere does ra_serf *unwrap* SVN_ERR_RA_SERF_WRAPPED_ERROR?
>
> % grep 'SVN_ERR.*SERF' subversion/*rf/*.[hc]
> subversion/libsvn_ra_serf/options.c:
> SVN_ERR_ASSERT(SVN_RA_SERF__HAVE_HTTPV2_SUPPORT(session));
> subversion/libsvn_ra_serf/options.c:
> SVN_ERR_ASSERT(!SVN_RA_SERF__HAVE_HTTPV2_SUPPORT(session));
> subversion/libsvn_ra_serf/serf.c: SVN_ERR_ASSERT(!
> SVN_RA_SERF__HAVE_HTTPV2_SUPPORT(session));
> subversion/libsvn_ra_serf/update.c: return
> svn_error_create(SVN_ERR_RA_SERF_WRAPPED_ERROR, err, NULL);
> subversion/libsvn_ra_serf/util.c: return
> svn_error_create(SVN_ERR_RA_SERF_SSL_CERT_UNTRUSTED, NULL, NULL);
> subversion/libsvn_ra_serf/util.c: err =
> svn_error_create(SVN_ERR_RA_SERF_WRAPPED_ERROR, err, NULL);
> subversion/libsvn_ra_serf/util.c: err =
> svn_error_create(SVN_ERR_RA_SERF_WRAPPED_ERROR, err, NULL);
> subversion/libsvn_ra_serf/util.c: err =
> svn_error_create(SVN_ERR_RA_SERF_WRAPPED_ERROR, err, NULL);
> subversion/libsvn_ra_serf/util_error.c: err =
> svn_error_create(SVN_ERR_RA_SERF_WRAPPED_ERROR, err, NULL);
> % grep 'SVN_ERR.*SERF' subversion/*{ra,client} | wc -l
Slightly more context:
I see 5 usages:
1:
/* Some errors would be handled by serf; make sure they really make
the update fail by wrapping it in a different error. */
if (!SERF_BUCKET_READ_ERROR(err->apr_err))
return svn_error_create(SVN_ERR_RA_SERF_WRAPPED_ERROR, err, NULL);
2:
if (err && !SERF_BUCKET_READ_ERROR(err->apr_err))
err = svn_error_create(SVN_ERR_RA_SERF_WRAPPED_ERROR, err, NULL);
3:
if (err && !SERF_BUCKET_READ_ERROR(err->apr_err))
err = svn_error_create(SVN_ERR_RA_SERF_WRAPPED_ERROR, err, NULL);
4:
if (err && !SERF_BUCKET_READ_ERROR(err->apr_err))
err = svn_error_create(SVN_ERR_RA_SERF_WRAPPED_ERROR, err, NULL);
5:
if (serf_err_msg)
{
err = svn_error_create(SVN_ERR_RA_SERF_WRAPPED_ERROR, err, NULL);
err_msg = serf_err_msg;
}
Which one is not specifically mapping specific error types?
Note that all of these cases handle specific APR error codes as specific for
SERF.
(except the last one of course)
Bert
Received on 2013-07-09 20:03:51 CEST