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

Re: svn commit: r1101918 - in /subversion/trunk/subversion/libsvn_ra_serf: locks.c update.c util.c

From: Greg Stein <gstein_at_gmail.com>
Date: Wed, 11 May 2011 15:35:19 -0400

On May 11, 2011 2:05 PM, "C. Michael Pilato" <cmpilato_at_collab.net> wrote:
> On 05/11/2011 12:00 PM, Daniel Shahaf wrote:
> >
> > When wrapping apr_status_t's returned by serf, shouldn't we decorate
> > them in some way so that code that interprets them knows to look them up
> > in serf.h:SERF_ERROR_* rather than in svn_error_codes.h ?
> >
> > Not sure, perhaps a wrapper err->apr_err link that signals to
> > subr/error.c to call into serf to stringify the child link...?
> I'm actually not sure that Serf even provides a stringification function
> all.

Good idea. I can fix that.

> svn_error_wrap_apr() will use 'status' as the err->apr_err value, but
> will call APR's stringification function which, I would expect, would just
> drop some generic string in place (since the Serf error code range is
> outside of APR's own). Of course, there's no guarantee that Subversion's
> and Serf's error code ranges won't overlap,

You have a guarantee :-)

> only that Serf's and APR's won't
> and that Subversion's and APR's won't.
> Perhaps the best short-term solution is to not use svn_error_wrap_apr(),
> to introduce svn_error_wrap_serf() instead, which can handle APR error
> as svn_error_wrap_apr() does, but map Serf error codes to something
> Subversion-ish.

Yup. For now, it can just call svn_error_wrap_apr, but we can update it
after serf exposes a new function. That will necessitate a 0.8 release.

Received on 2011-05-11 21:35:55 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.