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

Re: "svn status -u" doesn't report failure to connect to repository via DAV

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2003-09-17 22:30:25 CEST

Julian Foad wrote:
> cmpilato@collab.net wrote:
>
>> Julian Foad <julianfoad@btopenworld.com> writes:
>>
>>> If "svn st -u" can't contact the repository (via DAV), it proceeds
>>> without an error or warning, and prints "*" by every item. If it
>>> can't contact the repos via "file:", it prints an appropriate error
>>> message and quits, which I think is the right behaviour. Anyone
>>> have a fix for the case of DAV access?
>>
>> Hm. The '*' thing should only happen if it *can* contact the
>> repository and learns, by doing so, that the target of the status has
>> been removed from HEAD in the repository. Are the two RA layers
>> returning different errors from their RA->check_path() calls, or are we
>> even getting that far?
>
> Huh ... it returns a "generic error". Here's the relevant code from
> subversion/libsvn_ra_dav/props.c:
>
...
> else /* some error, read the comment below */
> {
> /* ### 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?
> */
>
> svn_error_clear (err);
> *kind = svn_node_none;
> return SVN_NO_ERROR;
> }

If it can't contact the repository because my PPP session is not connected, the error stack is:

svn: RA layer request failed
svn: PROPFIND request failed on '/repos/svn/trunk/doc/book/book/tmp'
svn: PROPFIND of '/repos/svn/trunk/doc/book/book/tmp': Could not resolve hostname `svn.collab.net': Host not found (http://svn.collab.net)

If it does contact the repository, but the item does not exist in the repository, the error stack is:

svn: HTTP Path Not Found
svn: PROPFIND request failed on '/repos/svn/!svn/bc/7078/trunk/doc/book/book/tmp'
svn: '/repos/svn/!svn/bc/7078/trunk/doc/book/book/tmp' path not found

This patch seems like an appropriate fix:

[[[
Prevent "svn status -u" from silently ignoring comms errors.

* subversion/libsvn_ra_dav/props.c
  (svn_ra_dav__do_check_path) Report "svn_node_none" only if the error was
    SVN_ERR_RA_DAV_PATH_NOT_FOUND; for other errors, propagate the error.
]]]

Index: subversion/libsvn_ra_dav/props.c
===================================================================
--- subversion/libsvn_ra_dav/props.c (revision 7078)
+++ subversion/libsvn_ra_dav/props.c (working copy)
@@ -1124,23 +1124,8 @@
       else
         *kind = svn_node_file;
     }
- else /* some error, read the comment below */
+ else if (err->apr_err == SVN_ERR_RA_DAV_PATH_NOT_FOUND)
     {
- /* ### 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?
- */

       svn_error_clear (err);
       *kind = svn_node_none;

It works for me. Shall I commit it if it passes the regression tests?

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Sep 17 22:30:15 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.