Greg Stein wrote:
> On Wed, Sep 15, 2010 at 13:29, Julian Foad <julian.foad_at_wandisco.com> wrote:
> > Bert, Erik, Greg...
> >
> > I think the schema should not disallow the 'excluded' presence in NODES
> > table where op_depth > 0 (which corresponds roughly to old
> > WORKING_NODE). There are already 'copy' cases where it is used, and
> > seems useful and right.
>
> Agreed.
>
> The doc for WORKING_NODE was simply out of date; we had agreed on
> allowing 'excluded' a while back.
>
> For example, I might have a directory with a huge subdir containing
> test-data which I've excluded in my local working copy, and want to
> make a new copy of that directory. I should be able to make the copy
> and commit it, where my new local copy continues to have no test-data,
> yet the repository *does* have that data.
>
> > I also think the schema should not disallow 'absent'. We have already
> > talked about how, if you allow a sub-tree copy (for example) to have a
> > child that is 'absent' (unauthorized), you won't be able to commit that
> > copy. But I don't think that means that the schema should forbid ever
> > representing such a case. I think if we forbid it at this level we
> > would possibly be making the rules more complex than they need to be and
> > would possibly run into problems later when we might find that actually
> > there are good cases to be made for representing such a state.
>
> I can see that reasoning, but I don't see that allowing it today
> simplifies anything. In fact, if we *do* see it today, then something
> has gone wrong.
>
> In the future, we can start writing 'unauthz' into the presence
> column, and then start interpreting it properly. That change in the
> future has no impact on today.
OK, that makes sense. I've added 'excluded' to the list of allowed
presence values in 'WORKING_NODE' and 'NODES' (op_depth > 0) in r997662.
> 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?
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.
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.
> * 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 (?).
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.
> * 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.
Previous encoding: presence==base-deleted; if it's the root, non-null
'moved_to', else scan_deletion reveals it's a move-away.
Benefits: Avoid scan_deletion.
> * 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.
> * added
A simple addition. Previous encoding: presence==normal,
copyfrom_*==null, scan_addition reveals it's a simple add. Benefits:
avoid scan_addition.
> Children of the root of the operation would have the same presence
> value. They can be detected as root vs children based on their actual
> depth vs their op_depth value. (I had previously pondered on some
> "inherit-*" presence values, but that is not necessary).
>
> (tho it could be argued that encoded the root/child concept into the
> presence would simplify the detection, compared to fetching the
> op_depth and performing a calculation)
>
> The following presence values would no longer be necessary:
>
> * base-deleted
>
> The following would not be used when op_depth > 0, but are still
> needed for op_depth == 0:
>
> * normal
> * not-present
>
> Thoughts?
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.)
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.
- Julian
Received on 2010-09-16 15:21:55 CEST