EXTERNALS table -- good or bad?

Hi all,

I have committed code to trunk that populates the EXTERNALS table during
upgrade from 1.6. With a nudge from Philip, I noticed that the EXTERNALS
table is still a neither-here-nor-there implementation. Now I'm unsure.

This table is / would be very useful if one tries to find all externals
defined or checked out in a given subtree, without having to first find and
then parse all externals skels.

But in fact it is little more than a cache for svn:externals props. It
duplicates information in a way. But it adds the knowledge of exactly which
repository and relpath an external is from (stores URLs in repos-root and
repos-relpath, readily parsed from the various formats found in
svn:externals definitions).

So it is useful for speeding up things, but it also has a danger: heavens
forbid if the EXTERNALS table is ever out of sync with the svn:externals
props. So, we may often be forced to parse the props anyway (cleanup?).

What do you guys think about the EXTERNALS table? Yay or nay? What thought
has gone into this so far?

Your answer is interesting to me right now because it will change the fixes
for file-externals-under-unversioned (WIP) and it will either shorten or
obsolete this nomination:

[[[
 * r1173574, r1174342, r1174693, r1174699, r1178910
   Fix issue #4016: 'externals after upgrade from 1.6 have wrong URL
   information in EXTERNALS rows'
   Also: previously, the first failing external upgrade aborted all other
   external upgrades, now just prints the error and carries on.
   Justification:
     Users will start upgrading their WCs soon, and it would be nice to
     have proper information in wc.db. I know of no real problems when
     EXTERNALS rows are wrong and/or missing info, but we might see them
     soon enough, or hit problems if same users upgrade same WCs to 1.8,
     much later.
     Argument against: "If EXTERNALS is just some sort of cache perhaps
       upgrade should just leave the columns null?"
     Argument for: "Currently 1.7 populates those columns. So upgrade
       should, too. We don't know which way we'll go -- drop EXTERNALS
       columns or heavily rely on them. So rather make an upgraded 1.6 WC
       look exactly the same as a fresh 1.7 WC would, saving us special
       cases in subsequent upgrade code. Meaning: power users with age-old
       WCs won't get dropped during upgrade to 1.8, whichever way we
       choose."
   Notes:
     r1173574 is just a cosmetic change that avoids conflicts in r1174693.
     r1174699 removes obsoleted stuff, but doesn't change the outcome.
     r1178910 fixes upgrade_tests.py 2 on windows.
     The entire patch seems quite large, but a large portion of it is just
     moving a function from static to private API.
   Conflicts:
     --accept=tc
     (r1174693, indent mismatch in handle_external_item_change() caused by
     cosmetic fix from r1169770)
   Votes:
     +1: neels
]]]

Thanks,
~Neels

(What is it with externals, that they always seem to bring out ambivalent
half-hearted implementations that have everyone stumped?)