"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
> - 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:
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.
Received on 2010-03-19 09:44:18 CET