Bert Huijben wrote on Tue, Jul 09, 2013 at 20:02:48 +0200: > > > > -----Original Message----- > > From: 'Daniel Shahaf' [mailto:d...@daniel.shahaf.name] > > Sent: dinsdag 9 juli 2013 18:39 > > To: dev@subversion.apache.org > > Cc: comm...@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? >
I don't understand the question. All 5 uses you paste above use SVN_ERR_RA_SERF_WRAPPED_ERROR in exactly the same manner: as a wrapper error code that is propagated directly to libsvn_ra's caller. What problem do you see in usage 5? > Note that all of these cases handle specific APR error codes as specific for > SERF. > (except the last one of course) > > Bert >
