Philip Martin wrote: > "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 actually don't see svn_wc_add4 creating a base node in this case. If it did, my problem wouldn't exist. (But I agree, the behavior would still be wrong.) But then, maybe I don't see it because I'm caching entries? > I'm currently looking at taking the entry_modify2 calls out of > svn_wc_add4 and making it create the WORKING_NODE directly. Xlnt! Meanwhile, I'll see what I can do with the file external business. -- C. Michael Pilato <[email protected]> CollabNet <> www.collab.net <> Distributed Development On Demand
signature.asc
Description: OpenPGP digital signature
