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