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
> "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
> "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
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
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
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,
Note that inherit-* nodes may not be reverted. The nearest "operation
root" (presence=added/copied/moved/deleted) should be reverted
> 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().
Received on 2010-04-08 02:59:26 CEST