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?)
signature.asc
Description: OpenPGP digital signature
