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
