Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification.
The "InheritedProperties" page has been changed by JulianFoad: http://wiki.apache.org/subversion/InheritedProperties?action=diff&rev1=26&rev2=27 * If a working copy child path doesn't find a parent with 'svn:inheritable:X' that it can inherit from before it reaches the working copy (or switched subtree) root, then it may inherit the property from the inherited properties cache (see below). {{{#!wiki note [JAF] What is the unifying principle behind the set of rules? For example, a principle could be:<<BR>> - "Inheritance within a WC is based on inheritance within a single revision of the tree structure. Thus, a WC base node inherits from its repository parent in its repository revision, no matter whether that is present in the WC. The 'actual' version of the WC tree is treated as a single revision: an as yet unnumbered prototype for a revision that might be committed into the repository (or might not)[1]. Thus, a WC actual node[2] inherits from the parent node that it would have in the repository if the current WC were committed in full."<<BR>> + "Inheritance occurs separately within each revision, and the WC 'actual' tree is treated as an unnumbered prototype for a revision that could potentially be committed[1]. Thus, a WC base node inherits from its repository parent node in its own revision in the repository, no matter whether that is the same as its WC parent node; and an 'actual' node[2] inherits from the parent node that it would have in the repository if the current WC were committed in full, no matter whether that is the same as its WC parent node."<<BR>> I think that principle would match all your rules if the 'mixed-revision' rule applies to actual nodes but not base nodes.<<BR>> [1] This particular principle for how we treat the 'actual' tree of a WC is something I've had in mind for a long time and I think it can be very useful in guiding how we design several aspects of WC behaviour, not just for inheritable properties.<<BR>> [2] By 'actual' version I mean the 'topmost' (i.e. MAX(op_depth)) version of the node in the WC, no matter whether that is different from or the same as the base version. @@ -73, +73 @@ {{{#!wiki note [PTB] JAF - I was envisioning a much simpler principle: Inheritance within the WC is within the actual tree[1]. This is easy for a user to explain and easy to understand. For example, no matter what the state of the WC a user can always say, "I see that 'my-WC/trunk' has the inheritable property 'InhPropName=PropVal'. That means that 'my-WC/trunk/README' inherits 'InhPropName=PropVal'. That makes sense!" If I understand correctly what you suggest, a user could face the case where a child path inherits a property value that differs from its actual WC parent's value (if it inherits anything at all). That strikes me as a recipe for user confusion. - [1] By actual tree I mean the topmost (i.e. MAX(op_depth)) version of the node in the WC, pretty much the same thing your 2nd footnote means(?). I thought we differentiated actual vs. working such that the former included property and text changes? + [1] By actual tree I mean the topmost (i.e. MAX(op_depth)) version of the node in the WC, pretty much the same thing your 2nd footnote means(?). I thought we differentiated actual vs. working such that the former included property and text changes? ([JAF] Yes, sorry for confusing terminology; I've adjusted my note to use 'actual'.) + }}} + {{{#!wiki note + [JAF] At each WC path there is potentially a base node, potentially some intermediate layers, and potentially an actual node. Each of the nodes has properties, which may include inherited properties. When you say "Inheritance within the WC is within the actual tree", precisely what do you mean? It seems clear you mean each actual node should inherit from its (WC path parent) actual node, but do you mean each base node should inherit from its (WC parent path) actual node as well? The latter sounds terribly wrong because a base node is supposed to represent a repository node, but now it would have a different set of inherited properties depending on the state of the WC.<<BR>> + In what I suggest, a child path base node would inherit from its repository parent, no matter whether that is the same as its its WC parent base node, because that maintains consistency, guaranteeing that particular node has the same set of properties no matter when and where you find it. As for the WC actual tree, our ideas are different but similar, but never mind that until we're clear on the basics. }}} 1. Note an important implication of #2 and #3: Unlike svn:mergeinfo, a child path with the svn:inheritable:X property explicitly set on it can also inherit the svn:inheritable:X property from a parent. Our default approach will be for child values to simply override parent values (exactly how svn:mergeinfo works today). However, the APIs will support getting both explicit and/or inherited property values. So it's possbile that child values might append to parent values or more complex merging of properties may be performed based on the specific property. 1. Unlike svn:mergeinfo, the property value a child inherits from a parent will not be modified based on the path-difference between the parent and child. The property value on the parent is the value the child will inherit.
