On Sunday 30 November 2003 12:55, Philip Martin wrote:
> John Szakmeister <john@szakmeister.net> writes:
> > I see the following happen in copy_versioned_files():
> >
> > SVN_ERR (svn_wc_adm_probe_open (&adm_access, NULL, from, FALSE,
> > FALSE, pool));
>
> This is a read-only baton so it doesn't create any locks.
Fair enough.
> > err = svn_wc_entry (&entry, from, adm_access, FALSE, subpool);
> > SVN_ERR (svn_wc_adm_close (adm_access));
> > if (err)
> > {
> > if (err->apr_err != SVN_ERR_WC_NOT_DIRECTORY)
> > return err;
> > else
> > svn_error_clear (err);
> > }
> >
> > and then once we determine there is a file to copy, this occurs:
> >
> > err = svn_wc_entry (&entry, copy_from, adm_access, FALSE,
> > subpool);
> >
> > Is this safe? According to svn_wc_adm_close's docstring, "Any physical
> > locks will be removed from the working copy. Lock removal is
> > unconditional, there is no check to determine if cleanup is required."
> > This sounds to me like we shouldn't be accessing the entry information
> > after we've closed the WC.
>
> With the current code the entry information will remain until the pool
> is cleared. I'm not sure that's something we want to guarantee, but I
> suspect it's not going to change. It probably would be better if we
> didn't access entry information after a baton is closed.
I figured it would sit in the pool (otherwise I would have seen problems when
the local export stuff), but it seems that this function is making use of an
implementation detail that isn't explicitly documented, which is why I had
cause for concern.
I'll look at getting this all squared away so that we no longer do that in
this function.
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Dec 1 01:09:23 2003