lundblad@tigris.org writes:
> Log:
> Fix a bug in "svn info", where it tried to fetch a repository lock
> for a path even if it was unrelated, or didn't exist in HEAD.
>
> [...]
>
> --- trunk/subversion/libsvn_client/info.c (original)
> +++ trunk/subversion/libsvn_client/info.c Mon Oct 10 07:36:02 2005
> @@ -356,19 +401,26 @@
> _("URL '%s' non-existent in revision '%ld'"),
> url, rev);
>
> - /* Possibly discover a lock attached to the remote URL. */
> - err = svn_ra_get_lock (ra_session, &lock, "", pool);
> -
> - /* An old mod_dav_svn will always work; there's nothing wrong with
> - doing a PROPFIND for a property named "DAV:supportedlock". But
> - an old svnserve will error. */
> - if (err && err->apr_err == SVN_ERR_RA_NOT_IMPLEMENTED)
> + /* Check if the URL exists in HEAD and refers to the same resource.
> + In this case, we check the repository for a lock on this URL. */
> + SVN_ERR (same_resource_in_head (&related, url, rev, ctx, pool));
> + if (related)
> {
> - svn_error_clear (err);
> - lock = NULL;
> + err = svn_ra_get_lock (ra_session, &lock, "", pool);
There's a small race condition here, no? HEAD could change between
the calls to same_resource_in_head() and svn_ra_get_lock(), so maybe
the resource still wouldn't be the same.
Of course, the bug is vastly less likely now, and I'll still vote for
this for 1.3. But is there anything we can do to close that window?
One way would be to loop like this (pseudocode):
while (1)
{
head = get_current_head()
same_resource_in_head (&related, ...);
svn_ra_get_lock (...);
if (get_current_head() == head)
break;
}
Note that calling same_resource_in_head() twice wouldn't work. The
resource at that path could change an arbitrary number of times
between any two function calls. So same_resource_in_head() could
answer yes, then svn_ra_get_lock() could return lock info for the
wrong object (!), and the next call to same_resource_in_head() could
once again see a related object at that path.
Thoughts?
-Karl
--
www.collab.net <> CollabNet | Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 10 18:53:19 2005