On Wed, Oct 12, 2011 at 3:38 AM, Neels J Hofmeyr <neels_at_elego.de> wrote:
> 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.
Hm, "should have been rolled out (by update)" vs. "has been rolled
out". We could also say that this is simply a bug: if something
obstructs the rolling out of an external, EXTERNALS should not reflect
that it was successfully rolled out. But again: I'm not the expert
here, I'm not 100% sure about all this.
> 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?
This problem exists just as well for dir externals. See "Handling
changes to svn:externals" in /notes/wc-ng/externals (the example given
there is with dir externals).
> 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.
Ok, but this is a pretty important use-case. Some users want to test
externals before committing them (which may entail changing+updating
them a couple of times before committing) . If EXTERNALS' sole purpose
would be to support this use-case: so what? Are you suggesting we
simply stop supporting that use-case?
> 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[1]. 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.
Not sure about the "just one corner case", but I still disagree that
it's a cache, and its purpose is optimization. No, its purpose is
keeping track of what was rolled out (maybe there are bugs in the
implementation, but I still think that that's the main responsibility
of this table). And that's a piece of information that isn't kept
anywhere else.
--
Johan
> 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 ;)
>
> ~Neels
>
> [1] 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 15:13:16 CEST