representational problem in the schema

Hey Hyrum,

I'm trying to work out the discrepancy in how we handle the COPIED
flag to satisfy both revert/17 and update/54. I figured out an
approach, coded something up, and it works. But then I started
thinking...

I should probably stop doing that. :-P

Consider the following BASE tree:

  A
  A/B
  A/B/foo
  A/C

Next, I delete the B directory. So we create two rows in WORKING:

  A/B, presence=not-present
  A/B/foo, presence=not-present

All good. Now, I copy A/C_at_rev to A/B. Now we have something like:

  A/B, copyfrom=blah
  A/B/foo, presence=not-present

Now. Just given the above data, talk to me about A/B/foo.

<pause>

Well.... there are two possibilities:

1) A/B/foo represents the deletion of the BASE node
2) A/B/foo represents a deletion of A/C/foo post-copy

I've been thinking about the best way to represent this in our schema.
I've come up with this approach:

* leave it untouched, but interpret case (2) as distinguished using
copyfrom records. we apply copyfrom info to the root of the deletion
from the copied subtree. if no copyfrom info exists on the deletion
root, then it represents a deletion from BASE

But this feels a bit fragile. Something could come along and overwrite
that node with other data, much like we overwrote A/B.

So. Something fully orthogonal. New column, or record "deletion roots"
or something...

After consideration, I'm thinking a new presence value of
"base-deleted". In the above two possibilities:

1) presence="base-deleted" means A/B/foo refers to the BASE
2) presence="not-present" means A/B/foo is a deletion of A/C/foo post-copy

Everywhere we talk about not-present, we'd have to extend a bit, and
probably adjust scan_working and crap.

Oh, and since A/B "shadows" a BASE node, then we implicitly know that
a deletion happened first, before <whatever> brought A/B into the
WORKING tree there (a replacement).

Thoughts?

Cheers,
-g

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1512688
Received on 2009-04-02 03:56:55 CEST