On Mon, Nov 25, 2019 at 12:03 PM Julian Foad <julianf...@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