On Mon, 31 Oct 2005, Stefan Küng wrote:
> Peter N. Lundblad wrote:
> > On Mon, 31 Oct 2005, Stefan Küng wrote:
> > Thanks for the patch. I'm not sure that this is the correct layer to fix
> > the problem. Would you care to check if this happens in the other RA
> > layers as well. This might be a bug deeper down in libsvn_ra_dav or
> > libsvn_repos.
> I don't think I can. I tried to find the place *where* this apr_error is
> set and couldn't even find that! I thought I could find the error define
> that way ;)
> Also, I think this *is* the right place to fix this bug (but of course I
> don't know the internals that well, so chances that I'm wrong are very
> The function same_resource_in_head() calls svn_client__repos_locations()
> which returns the error SVN_ERR_FS_NOT_FOUND. And as I see it, this is
> correct if the path doesn't exist. But same_resource_in_head() is the
> function which should not pass that error on, because it's docstring says:
> /* Set *SAME_P to TRUE if URL exists in the head of the repository and
> refers to the same resource as it does in REV, using POOL for
> temporary allocations. RA_SESSION is an open RA session for URL. */
When I wrote same_resource_in_head, I looked at the docstring of
svn_client__repos_locations, which says that if start_rev or end_rev is
greater than peg_rev, it will check that the paths are related, and if
this check fails, return SVN_ERR_CLIENT_UNRELATED_RESOURCES. I don't
believe returning FS_NOT_FOUND is correct in this case.
> So *SAME_P* must not be TRUE if the URL does not exist in HEAD. Of
> course, it isn't true without my patch either, but it throws an error
> which it shouldn't in that case. IMHO same_resource_in_head() has to
> check SVN_ERR_FS_NOT_FOUND too, because that's just one more sign that
> not a 'real' error occurred but that the resources aren't the same.
> Other errors like auth failures for example are 'real' errors for that
> function too, but not SVN_ERR_FS_NOT_FOUND.
Yes, it shouldn't return that error.
> About other RA layers: this function is called from all RA layers, not
> just DAV.
Yeah, it will be called regardless of which RA layer is in use, but it
will *call* functions specific to the RA layers. What I want to know is fi
this is specific to ra_dav.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Mon Oct 31 14:59:38 2005