[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Problem in copy_versioned_files()?

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2003-11-30 18:55:46 CET

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.

> 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.

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Nov 30 18:56:18 2003

This is an archived mail posted to the Subversion Dev mailing list.