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

Re: error not passed to clients

From: SteveKing <steveking_at_gmx.ch>
Date: 2003-09-03 14:38:01 CEST

----- Original Message -----
From: "Ben Collins-Sussman" <sussman@collab.net>

>
> > Is it possible to pass such errors to clients?
> >
>
> I think this sounds like a reasonable request. If an application runs
>
> svn_client_status ("-u", ...)
>
> ... and a network error happens, that function should definitely throw
> the error back to the application, not silently return status data
> that's missing network information.
>
> I'm not really familiar with all the new streamy status code that
> cmpilato wrote last week. Is it an easy fix? If so, can someone
> post/test a patch?

I tried to trace the functions from the prompt callback back
to the status function. While doing that I found a comment
in the file libsvn_ra_dav/props.c (right at the bottom of the file):

/* ### This is way too general. We should only convert the
* error to `svn_node_none' if we're sure that's what the error
* means; for example, the test used to be this
*
* (err && (err->apr_err == SVN_ERR_RA_DAV_PROPS_NOT_FOUND))
*
* which seemed reasonable...
*
* However, right now svn_ra_dav__get_props() returns a generic
* error when the entity doesn't exist. It's APR_EGENERAL or
* something like that, and ne_get_status(req)->code == 500, not
* 404. I don't know whether this is something that can be
* improved just in that function, or if the server will need to
* be more descriptive about the error. Greg, thoughts?
*/
 
Maybe this helps someone who's familiar with the code?
I don't know how to fix this myself since I got completely lost
in the neon functions...

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Sep 3 14:39:32 2003

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.