[Adding Blair Z. explicitly to the distro list]
Greg Stein wrote:
> There are two short answers to your question:
>
> 1) we don't have a good handle on what to do with file externals in
> wc-ng (we temporarily punted)
> 2) per the doc in BASE_NODE, file externals are just a copy of an
> existing property, so we shouldn't need to duplicate the values into
> another column
I think the doc might be misleading. The file external information is a
copy of the details from an existing property (the svn:externals property)
*set on a different resource* (the directory in which the external lives).
It's like like the external file is carrying the same data itself in two
places or anything.
> I'd be interested in asking why a separate column is needed.
Currently it's needed as a flag for special behaviors in the high-level
operational logic of switch, commit, copy, delete, status, etc.
(Interestingly, these behaviors don't even note the details of the external
definition, just its presence/absence. So in that sense, we appear to
already be storing more information than we really need.)
> Can the file externals code be rearranged to more directly interpret
> svn:externals as needed, rather than referring to custom metadata?
I suppose instead of checking for this property on the external target file
itself, we could query the svn:externals property of the parent directory,
parse it, decide if any of the settings apply to the external target file,
decide if they *have been* applied, etc. Just seems sloppy.
One would be to support this information in the WORKING_NODE schema, too,
stashing it there instead of in the BASE_NODE at the time it is created, and
promote it into the BASE_NODE when the switch occurs. But that implies that
working nodes can have this value set independently from their respective
base nodes, and that's just wrong.
The right thing would be for the switch operation itself to somehow either
detect that it is being called on a file external target or be told. Being
told by code that already knows makes more sense than trying to infer the
state in code that doesn't. But being told probably means exposing the file
external notion through the public API. Thus far it seems the file external
code was intended to slip it unnoticed as an implementation detail. Maybe
it's time we claim ownership of this feature and build API support for it.
Blair, have you any thoughts on the matter?
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2010-03-19 16:47:21 CET