Greg Stein wrote: > On Wed, Sep 15, 2010 at 13:29, Julian Foad <julian.f...@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
