holes in the WC-NG schema?

Greg Stein wrote:
> Oh no no no... the schema is fully set up to record moves properly,
> without any guesswork. It is just that nobody will invoke the function
> (in 1.7!) to do the recording.
>
> I'm comfortable that the schema will work. Please feel free to analyze
> it for holes. But you're looking at the 'moved_here' and 'moved_to'
> columns. You're also going to want to learn about scan_addition() and
> scan_deletion() in more detail.

I remember someone talking of a hole. It went something like: If a folder is
copied-here, all its children have locally added status, and I understand
they refer to the op-root of the add to find out their history, i.e. that
they are copied. Now what if I replace such a child node with a fresh, new
node -- it will still think that it's part of the copy-here. Just vague
memory, haven't verified. This one should be fixed if it turns out to be so.

I also know of another potential "future hole": If I add a node, it
remembers the URL at which it wants to be added, which is derived from the
parent during the 'add' operation. If I then even switch the parent away
--depth=empty, the added child node still remembers its original URL. That
is pretty cool. But, we have two places where we also may want to know the
*revision* that the parent had at the time of the 'add' (which should also
step up when 'svn update's happen):

- The first place is svn_client__get_revision_number() with a revision of
svn_opt_revision_working or _base. This function returns a (much overloaded)
revision number, which is derived from the parent in some added-cases. In
above case (switched-away parent from a locally added child), deriving from
the parent is not possible anymore. Regardless, we do not want to look up
parents at all.
... But chances are good that we can eliminate this case by refactoring a
few callers, properly defining svn_opt_revision_*'s meaning for added nodes
to be SVN_INVALID_REVNUM, and coining it an API error, or something.

- The second place is tree-conflict info. (This is a slightly odd concept,
but it makes sense:) If a tree-conflict happened on a locally added node,
'svn info' would like to tell the user at which URL_at_REV this added node was
*known to not exist*. We can get the URL easily, today. But the revision is
missing. That's why 'info' currently just prints "(none)" in that case.
I'm loosely thinking of an "added-at-rev" column in the NG-WORKING table,
which is derived from the parent during 'svn add', and is updated during
'svn update' and 'svn switch' (here --depth=infinity).
But frankly, this info output is not that pressing really. Just noting this
to indicate that this particular useful information is currently not
available in the schema.
(There is another situation that is related -- saying this here because it
illustrates how "real code" can just "cheat" around not having an
added-onto-revision. Philosophical experiment: If we had this data of
'revision-onto-which-node-is-added', a locally added node may,
hypothetically, *be detected to be out-of-date* in the same way that locally
modified nodes are; that would force an 'svn up', which would cause a
tree-conflict if this path has also been added in the repos. Currently, we
don't detect that, try to commit, which fails with an error and *not* a
tree-conflict. In reality, this can simply be fixed by saying 'out-of-date'
instead of erroring when we hit a local-add vs. repos-add during commit; it
obviously doesn't really need the revision.)

I'm, thirdly, wondering if we can really express all sorts of madly
cascaded/circular local copies/moves/deletes/replaces from/to subtrees that
make sense to our users... a proper test suite will tell, right, stsp? ;)

~Neels