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

Re: Cannot get info for a file that was inside of file-replaced directory

From: Nathan Hartman <hartman.nathan_at_gmail.com>
Date: Tue, 26 Nov 2019 12:21:59 -0500

On Mon, Nov 25, 2019 at 12:03 PM Julian Foad <julianfoad_at_apache.org> wrote:
>
> TL;DR: Fixed and nominated for backport.

Thank you!!

More below...

> > (2) Alternately, perhaps svn_client_info4() should remain as-is and
> > instead same_resource_in_head() should change: Maybe under certain
> > conditions that currently return an error, it should instead
> > set *same_p = FALSE and return SVN_NO_ERROR?
>
> Yes, (2): it already checks for two error codes:
>
> ((err->apr_err == SVN_ERR_CLIENT_UNRELATED_RESOURCES) ||
> (err->apr_err == SVN_ERR_FS_NOT_FOUND)))
>
> we need to add:
>
> (err->apr_err == SVN_ERR_FS_NOT_DIRECTORY) ||
>
> Fixed: http://svn.apache.org/r1870395
>
> This does beg the question of what is the total set of possible failure
> modes that should be handled the same way.

I went through the list of error in svn_error_codes.h one by one and
two possibilities came to mind:

The first is SVN_ERR_FS_NOT_FILE. I wonder if this code would appear
and cause a failure if a similar test is run, but replacing a file
with a directory instead of replacing a directory with a file... I'll
test that scenario a little later...

The second possibility has to do with authz somehow causing a same-
resource check to fail (object accessible in old revision but not new
revision). I suppose that under this scenario, the error message would
say something to that effect.

Nathan
Received on 2019-11-26 18:22:15 CET

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.