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
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) ||
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.
Received on 2019-11-25 18:03:17 CET