Philip Martin wrote:
> "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 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 <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2010-03-19 16:05:21 CET