On 10/11/2011 01:29 PM, Johan Corveleyn wrote:
>>> AFAIUI, the EXTERNALS table is indeed not a cache, but it notes the
>>> externals "as rolled out by the last svn update", i.e. the externals
>>> "as currently expanded in the WC" (at least, that's what I understood
The EXTERNALS table does not track what is currently rolled out (e.g. can't
possibly keep track of file-system rm/mv). Rather, it tracks what should be
rolled out. An external definition may already be in the EXTERNALS table,
but not yet checked out in the WC; for example, if, at the time the external
def was added, there was an obstruction at the target path. Until that
target path is freed up, the row will remain in the EXTERNALS table even
though it does not reflect what is currently rolled out.
Specifically, a *file* external that is fully and correctly rolled out has a
file_external==1 column in its NODES table's BASE row (op_depth==0) as well
as its own repos_id and repos_path.
But it is possible that a file external is already noted in an EXTERNALS row
while a different dir or even file (with file_external==0) is still
currently checked out at that path. From examining NODES and the fs, it can
be identified whether the file external is rolled out yet or just
obstructed. There can even be no NODES row at all, in which case a file
lying at the target path would be known as unversioned, obstructing the
external. I think there can even be another file external at the same path,
and even though its BASE row says file_external==1, lib_wc would still
notice if it was a file extl from a different URL (haven't checked this one).
To know that a *dir* external is fully rolled out, a WC dir at the
external's target path has to be a WC-root and has to match the external URL.
Now take the situation that some externals are defined and rolled out. All
is well. If now someone changes the svn:externals prop, it is necessary to
know what the desired externals situation was before that change.
In notes/wc-ng/externals, the EXTERNALS table is stated to solve this
problem. Yet the problem only exists for file externals and only when
locally changing the svn:externals prop multiple times without committing?
As it looks to me, the area where the EXTERNALS table is not a cache is
really quite narrow. IIUC the area is exactly confined to this use case:
User does several propchanges on svn:externals,
with intermediate 'svn update' calls.
In this case the WC only notices the BASE's svn:externals prop; but upon
comparing to the currently checked out node at the target path, to determine
whether that node is an obstruction or the actual external, the WC has to
remember what this externals node was desired to be, during the last 'svn
update'. -Only- in the above use case, this differs from BASE's
svn:externals prop. ... A 'commit' moves the new prop to BASE and this
problem disappears. So "most of the time", EXTERNALS *is* just a cache.
I still think this table is useful for quick scanning for presence of
externals. But for that purpose I guess it *could* simply list which
paths are externals and where they are defined, so that you can go straight
to the defining path and parse the details from the property. It currently
seems to be a mere added bonus/optimization that the table reflects the URL,
kind etc. all of the time, instead of just in the use case of multiple
'propset svn:externals' & 'update' cycles.
EXTERNALS is almost pure optimization, just one corner case really dearly
*needs* it. Please correct me if I'm wrong.
Still I'm +1 for keeping it this way, because it seems silly to parse all of
the props from a given node's skel blob, and to then parse all of the lines
in the svn:externals prop, just to get at one extl definition.
I wish I could have said this in fewer words and same detail...
Re: documentation of the EXTERNALS table: large amounts of wc-ng are
chronically under- and even misdocumented. Greg kept saying "moving
target!", and for him code *is* comment, -- and hence this thread ;)
 need to scan for externals e.g. during svn cp wc/a wc/b, and in svn
status for externals-below-unversioned or -below-other-wc (WIP)
Received on 2011-10-12 03:38:43 CEST