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

Re: Need help with "the WC-NG way" of dealing with file externals.

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Fri, 19 Mar 2010 08:43:41 +0000

"C. Michael Pilato" <cmpilato_at_collab.net> writes:

> See, in subversion/libsvn_client/externals.c:switch_file_external(), there
> is logic around file external handling that basically looks like this:
>
> - create a file scheduled for addition (using svn_wc_add4)
> - set the magic file_external_* bits on that file's entry
> (svn_wc__set_file_external_location)
> - switch the file to the external location (svn_client__switch_internal)
>
> In the current codebase, that works fine because that second step is using
> svn_wc__modify_entry2() which actually creates a BASE_NODE row for the new
> file with the file_external_* bits set. But I think this is a bit of a
> stretch in terms of legitimacy. Until the switch happens, this is just a
> new file scheduled for addition, right? There shouldn't be a base node for
> that object at all.

It's a bug that svn_wc_add4 creates a base node:

http://subversion.tigris.org/issues/show_bug.cgi?id=3584

There is also an entries caching bug associated with add: the cached
entries it creates and uses don't always match the database (compile
lock.c with SVN_DISABLE_ENTRY_CACHE to make this more visible). There
is already some code that works around the entry caching problem, see
the lines marked EBUG in update_editor.c:merge_file.

I'm currently looking at taking the entry_modify2 calls out of
svn_wc_add4 and making it create the WORKING_NODE directly.

-- 
Philip
Received on 2010-03-19 09:44:18 CET

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.