[Subversion Wiki] Update of "InheritedProperties" by JulianFoad

[Apache subversion Wiki <co...@subversion.apache.org>]

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=54&rev2=55

Comment:
Delete my questions and Paul's answers from the WC Inheritance Rules section, as I understand the rules now and I don't think the Q&A helps anyone.

    1. A path in a modified working copy effectively inherits properties from the proto-revision that any modified WC represents (a set of changes that could potentially be committed as a new revision).
    1. Mixed-revision working copies are similar to #2 except that there is no proto-revision.  So unlike svn:mergeinfo and like tsvn:auto-props, inheritance across mixed-revision boundaries in the working copy is allowed by default.
   Leaving Julian's questions for now...
-  {{{#!wiki note
-     [JAF] What is the unifying principle behind the set of rules?  For example, a principle could be:<<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.
- }}}
-   . {{{#!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?  ([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.
- }}}
  
  === Inherited Properties Cache ===
  A child path that inherits a property from its parent may not have ready access to that parent in the working copy (e.g. the root of the working copy is a subtree of the parent path).  To ensure that traditionally disconnected operations (i.e. those that require no access to the repository, like 'svn add') remain disconnected, we will maintain a cache of properties inherited by the root of the working copy. Whenever a new working copy is checked out, any properties inherited by the root of the working copy will be cached in the working copy.  If a subtree within a working copy is switched, a separate cache will be created for the root of that subtree.  File externals will have their own cache as well.  Whenever the WC is updated the cache(s) will be refreshed.