revamping the presence values (was: wc-ng base/working nodes in a copied tree)

On Tue, Apr 6, 2010 at 23:50, Greg Stein <gstein_at_gmail.com> wrote:
>...
> I'm thinking that we add the following presence values (for
> WORKING_NODE.presence):
>
> "added": same as "normal" today. clarifies what this really means. we
> map this to status_added, so why not use this for the presence
> anyways? no need to "minimize/conserve" the set of presence values.

Note this presence also covers copied-here and moved-here.

However, back to the "why try to conserve presence values?" question,
we could create "copied-here" and "moved-here" presence values. This
would eliminate the moved_here column.

We could also answer certain questions for this node without a call to
scan_addition.

> "replaced": indicates an added/copied-here/moved-here node that
> replaces a child of a copied-here/moved-here subtree.

I think this is not required. We can always look at a "previous layer"
to see whether this replaces anything, or is a plain add. For example,
let's say our node in question is A/B/C. Thus, its op_depth is 3. The
query to detect a replacement is:

SELECT 1 FROM NODE_DATA
WHERE wc_id = ?1 AND local_relpath = 'A/B/C' AND op_depth < 3
LIMIT 1

If any rows are returned, then this "added" (or "copied-here" or
"moved-here") node is replacing a BASE node or an ancestor's child
(op_depth can be used to discriminate these two cases).

> "deleted": same as "not-present" today. clarifies what this really means.

I believe that we can eliminate the "base-deleted" presence. For
example, let's say that we had the following tree and presence values:

A/B/file1 : presence=deleted
A/B/file2 : presence=base-deleted

file2 is using base-deleted to indicate that the BASE node A/B/file2
was deleted somehow (maybe this node, or as part of an ancestor).
file1 is deleted because it is a child of A/B, which was copied-here.

Now... with the new NODE_DATA and op_depth capability, we can
distinguish these two cases.

SELECT op_depth FROM NODE_DATA
WHERE wc_id = ?1 AND local_relpath = ?2
ORDER BY op_depth DESC
LIMIT 1

For file2, there was never an ancestor copy that created it, so the
result of the above query is op_depth==0 (the BASE node).

For file1, it will be 1 or 2, depending on where the copy occurred (A,
or A/B, respectively).

Depending upon the exact question... maybe it is "is the BASE node
being deleted?", then the query can be adjusted:

SELECT 1 FROM NODE_DATA
WHERE wc_id = ? AND local_relpath = ?2 AND op_depth > 0
LIMIT 1;

This eliminates the ORDER BY. If any rows are returned, it is a
deletion of a child node. If NO rows are returned, then the BASE has
been deleted. (of course, a BASE could *also* be deleted, in addition
to a child; like I said, it depends upon the question you're asking)

> "inherit": applied to children of copied-here/moved-here and
> deleted/base-deleted nodes. implies that no commit operations are
> required for these nodes.

I think we still need these in the WORKING_NODE tree. Potentially
divided into: inherit-copy, inherit-move-here, inherit-move-away,
inherit-delete

Note that inherit-* nodes may not be reverted. The nearest "operation
root" (presence=added/copied/moved/deleted) should be reverted
instead.

> The APIs from wc_db should remain the same. This is a database-only
> change. The concepts are surfaced through read_info(),
> scan_addition(), and scan_deletion() as before.

This is still true. We can leave it unchanged, or we can start to
return more status values from read_info().

>...

Cheers,
-g
Received on 2010-04-08 02:59:26 CEST