[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: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2003-12-10 05:24:22 CET

Julian Foad wrote:
> John Szakmeister wrote:
>> On Saturday 06 December 2003 21:21, Julian Foad wrote:
> [...]
>>> /* Recurse if required, unless we have just removed the entire directory. */
>>> if (recurse && svn_wc_adm_locked (adm_access))
>>> This works because if the directory was removed,
>>> svn_wc_remove_from_revision_control->svn_wc__adm_destroy->svn_wc_adm_close
>>> will have marked the access baton as not having a write lock. (Actually,
>>> the status is explicitly set to "closed" but my zeroing it out interferes
>>> with that and changes the status to "unlocked". Either way is sufficient
>>> for this to work, but it is unclean.)
>> Good idea!
>>> I think this patch now fixes the used-after-closed errors: all tests pass
>>> on Linux over RA-local and RA-svn. The only question I have is whether we
>>> want the baton-invalidation step to be checked in. If so, should it set
>>> various fields individually instead of doing a "memset"?
>> Oof, good question. I personally like it because it forces us as
>> developers to adhere to the API. I'm not sure it useful outside of
>> that though. I'm in favor of the memset() since if the baton changes
>> for some reason, it's less code to update.
> Maybe it (and other debug-only things like the "file" and "line" fields
> of svn_error) should be wrapped in "#ifdef DEBUG" or similar.
> I've committed it as it is, in r7961.

... and reverted it in r7966 due to Philip Martin's objections (with which I agree). See thread "svn commit: rev 7961 - trunk/subversion/libsvn_wc".

- Julian

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Dec 10 05:18:51 2003

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.