"C. Michael Pilato" <[email protected]> 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
