On Thu, Sep 16, 2010 at 09:21, Julian Foad <julian.f...@wandisco.com> wrote: > Greg Stein wrote: >... >> Also, please note that I want to expand the presence values >> dramatically with this move to NODES. I suggest the following new >> values: > > Can you explain what these would mean, and what are the main advantages?
Primarily: no need to scan to figure out what is going on. > Some of them look obvious at first glance but the details of > child-of-copy etc. are quite complex. If I were to start to guess... > > For op_depth = 0, we keep using the current set of 'presence' values, as > defined for BASE_NODE. Yes. > For op_depth > 0, these new values replace the old 'normal', > 'base-deleted' and 'not-present' presence values and the old > 'moved_here' flag. The old 'excluded' and 'incomplete' are still used. Yes. >> * copied [-here] >> * moved-here > > This is a root or a child of a copied/moved sub-tree. 'op_depth' > compared with 'local_relpath' depth indicates whether it's the root. > 'copyfrom_*' is non-null iff it's the root (?). Correct on all three parts. Note: the columns should be named original_* or repos_*, as discussed elsewhere. > Previous encoding: If it's the root, presence==normal + non-null > 'copyfrom_*' + 'moved_here'=FALSE/TRUE. If it's a child, > presence==normal and scan_addition reveals it's part of a copy/move. > > Benefits: Avoid scan_addition. Remove the 'moved_here' flag. Yes, yes. >> * moved-away (aka deleted) > > This is a root or a child of a moved-away sub-tree. The new WC > location (local relpath) is in 'moved_to' iff it's the root. Correct. With root detection based on op_depth and local_relpath as mentioned above. > Previous encoding: presence==base-deleted; if it's the root, non-null > 'moved_to', else scan_deletion reveals it's a move-away. The presence could be 'deleted' if you were moving a child of a copy/move-here. But note that wc_db does not implement moves, so we never got to these encoding details. > Benefits: Avoid scan_deletion. Yes. >> * deleted > > This node is deleted relative to the layer below. Previous encoding: > 'base-deleted' or 'not-present' depending on whether it was a child of a > copied subtree. Correct. >> * added > > A simple addition. Previous encoding: presence==normal, > copyfrom_*==null, scan_addition reveals it's a simple add. Benefits: > avoid scan_addition. Yes on all. >... > Are my notes close to what you were thinking? (I'm trying to write out > the states in a table to be more rigorous about it.) Spot-on :-D (part of the reason to expand the set: their semantics become obvious, compared to the current encoding) > If this does enable us to eliminate the use of scan_addition and > scan_deletion in some cases, even if they (or some simpler versions) are > still needed for finding the copyfrom info in other cases, that would be > a worthwhile change. I was originally trying to be minimalist with the presence values, but after use/implementation it became obvious that we can simply encode operations in the nodes rather than requiring a scan for them. scan_addition will receive the most benefit since it resolves an "add" to an "add/copy-here/move-here". Or in today's implementation add vs copy. The scan_deletion never really has to resolve since we don't truly implement moved-away. The *concepts* are still in the code because I think we need the design and direction rigor. For the 1.7 release, we should keep scan_* and just change their internals. We can rethink other APIs for future releases since these are internal to WC. The implementation is generally reading just a row or two: read the target row, examine its op_depth, and read the operation root's row. We don't have to scan upwards to find the operation root. Cheers, -g
