On Tue, Apr 6, 2010 at 23:50, Greg Stein <[email protected]> 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
