[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] NODES table presence values

From: Greg Stein <gstein_at_gmail.com>
Date: Mon, 20 Sep 2010 13:17:24 -0400

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

This is an archived mail posted to the Subversion Dev mailing list.