On Thu, Sep 16, 2010 at 09:21, Julian Foad <julian.foad_at_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
Received on 2010-09-20 19:18:05 CEST