On Tue, 2010-10-05, ehu_at_apache.org wrote:
> Author: ehu
> Date: Tue Oct 5 19:56:52 2010
> New Revision: 1004792
>
> URL: http://svn.apache.org/viewvc?rev=1004792&view=rev
> Log:
> * notes/wc-ng/nodes: Add more explanation of how the table works.
Excellent! We can much more easily agree and disagree consistently now!
> Modified:
> subversion/trunk/notes/wc-ng/nodes
>
> Modified: subversion/trunk/notes/wc-ng/nodes
> URL: http://svn.apache.org/viewvc/subversion/trunk/notes/wc-ng/nodes?rev=1004792&r1=1004791&r2=1004792&view=diff
> ==============================================================================
> --- subversion/trunk/notes/wc-ng/nodes (original)
> +++ subversion/trunk/notes/wc-ng/nodes Tue Oct 5 19:56:52 2010
> @@ -9,7 +9,11 @@ Description of the NODES table
> * Ordering rows into layers
> * Visibility of multiple op_depth rows
> * Restructuring the tree means adding rows
> - *
> + * Copies of mixed-revision subtrees become multiple layers
> + * In a deleted subtree, all nodes get marked deleted explicitly
> + * Nodes in a replaced subtree can have different presence values
> + * Presence values of nodes in partially overlapping replacements
> + * Status needs to consult the *two* topmost layers - sometimes
>
>
> Introduction
> @@ -149,6 +153,65 @@ itself can be reverted during the next r
> the same op_depth...
>
>
> +Copies of mixed-revision subtrees become multiple layers
> +--------------------------------------------------------
> +
> +In the design, every node which is not a child of its parent implies a
> +tree restructuring operation having taken place. When committing a
> +mixed-revision subtree, the commit should mirror the actual mixed state
> +of the tree.
> +
> +A mixed-revision tree which came about in the usual process of committing
> +content changes - ie one without tree modifications - differs exactly in
> +that respect: the tree in the repository doesn't need to mirror the mixed
> +revision state in the working copy.
> +
> +The idea is that every tree restructuring operation takes place on the
> +oproot. When a node or subtree within the copied tree isn't a direct
> +child of its parent, most notably because it's at a different revision,
> +that's a tree restructuring: a node of the same revision has been
> +replaced by a node (of the same name) from another rev.
> +
> +By strict application of the design rule, all nodes and subtrees at
> +different revision levels than their parents within the copied subtree,
> +become an op_depth layer of their own.
Pasting, slightly tweaked, what I said on IRC:
We don't have the info in the WC to be able to fill in the lower layers
of this tree for the copy, if we are copying from BASE, because BASE is
stored flat. Therefore we won't be able to revert/delete/replace the
different-revision sub-trees of this copied tree. Therefore I think we
have to store the mixed-rev copy flat (single op_depth) and modify the
commit rules to act on revision-number changes within this flat tree.
Earlier today on IRC, Philip and I came to the conclusion that a copy of
a mixed-rev subtree (at least from BASE) should be all at the *same*
op_depth.
Spreadsheet
<https://spreadsheets.google.com/ccc?key=tDp6pZ5yOYZvkGSZMeHgx-Q&hl=en&authkey=CJz6v4QK#gid=2>, sheets 1 and 2, show the difference, with a comment saying why I thought it didn't work. Re. node 'copy/A/f' on sheet 2: putting this at op_depth=3 meant there was no way to represent further changes - at least not a replacement - of that node, because the "repo/rev/relpath" reference is already used.
If the idea is that the copy { copy/A_at_10, copy/A/f_at_12 } is *by design*
two separate restructuring changes, then deleting or replacing
'copy/A/f' certainly would be possible: to delete it, we delete the
op_depth=3 row to reveal { op_depth=2 copy/A/f_at_10 }. But, as that
spreadsheet shows, there is 'no row' at op_d=2. To represent this
properly as a tree change, the op_d=2 column should contain a complete
copy of the 'A_at_10' subtree. But we don't have that information in the
WC, because the BASE column is FLAT. (If BASE was stored in the same
layered way, then we could do it.)
- Julian
> +
> +In a deleted subtree, all nodes get marked deleted explicitly
> +-------------------------------------------------------------
> +
> +All nodes in a deleted subtree get marked 'deleted' explicitly in order
> +to be able to query on a single node and find in its topmost layer
> +that the node that might have ever existed at the given path does not
> +exist there anymore.
> +
> +
> +Presence values of nodes in partially overlapping replacements
> +--------------------------------------------------------------
> +
> +Replacement - being a two-step operation consisting of a delete and an
> +add/copy - causes all rows of the deleted subtree to be added with a
> +new op_depth and presence value 'deleted'. So far so good.
> +
> +Adding a tree on top of the same oproot will cause the oproot -
> +and all overlapping children! - to switch their presence value to
> +'normal'. The children should not be considered a replacement or
> +addition: their tree depths don't correspond to the op_depth, meaning
> +the nodes themselves should not be considered restructured.
> +
> +
> +Status needs to consult the *two* topmost layers - sometimes
> +------------------------------------------------------------
> +
> +As discussed before, every tree restructuring operation becomes an
> +oproot, causing rows to be added with a new op_depth value.
> +
> +Status wants to report the oproots, making a clear distinction between
> +adds and replacements. However, both added and replaced nodes have
> +the presence value 'normal'. In order to make the distinction, status
> +needs to determine if there was a node in the layer below the
> +restructured layer. In case there is, it must be a replacement,
> +otherwise, it must be an addition.
>
>
>
>
>
Received on 2010-10-05 22:55:16 CEST