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

TL;DR: Fixed and nominated for backport.

I see it was a change I made that broke this case.

Filed as: http://subversion.apache.org/issue/4837

Test added: http://svn.apache.org/r1870393

More below...

Nathan Hartman wrote:
[...]
> (1) This line in svn_client_info4():
>
> SVN_ERR(same_resource_in_head(&related, pathrev->url, pathrev->rev,
> ra_session, ctx, pool));
>
> would terminate if any error occurs in same_resource_in_head().
> Perhaps we should: check the specific error code; consider certain
> error codes as signifying that the object is not locked, set
> lock = NULL, and proceed?
>
> (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.

We really ought to:
   * do random testing (svn info on all sorts of combinations of paths)
   * group error codes better so we don't have to guess what ones to expect

> (4) Optimization: Currently same_resource_in_head() is being called
> unconditionally. Perhaps this should not be called at all if there
> are no locks?

Someone could look into the pros and cons of switching the order (query
for locks first, then check relatedness) as a separate exercise. We
currently have no indication that would be an optimization in general;
it would be different in different cases. There are cases like
recursive info request to consider. It doesn't sound like a priority.

While those follow-ups remain possible, the basic issue is fixed.

Nominated for backport to 1.10 and 1.13.

- Julian
Received on 2019-11-25 18:03:17 CET