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

["C. Michael Pilato" <cm...@red-bean.com>]

I started yesterday trying to convert a bit of svn_wc_entry_t-wielding code
related to file externals into WC-NGness.  I thought I had identified an
easy abstraction of some related code, so I made that abstraction and found
that it was a miserable failure.

I'm attaching two patches.  The first (file-externals-abstraction-patch.txt)
just carves some code out of the entry-writing logic and drops it into
wc_db.[ch].  This patch works fine.

The second (file-externals-definition-patch.txt) was where I thought, "Hey,
I can re-use the code that sets the file_external_* bits of the entry here,
too!"  I was wrong.  And though it took me far too long to do so, I think I
finally realize why I was wrong.

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.

My patched code doesn't work because there's not yet a base node for the new
file, so attempts to update the file_external_* data on that base node
silently fail.

Clearly the code wants to hang this file external information somewhere.
The WORKING tree lacks schema support for it.  The switch logic needs it to
make decisions about what it's doing, but it seems wrong to pass this bit of
hackery through the public update/switch API.  I hesitate to hack in yet
another "private" workaround API.

Anybody got any bright ideas or precedent that I can refer to?

-- 
C. Michael Pilato <cm...@red-bean.com> | http://cmpilato.blogspot.com/