[Subversion Wiki] Trivial 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=25&rev2=26

Comment:
Switch the terminology in my note from 'working version' to 'actual version'.

    * 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 working 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 working node[2] inherits from the parent node that it would have in the repository if the current WC were committed in full."<<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>>
-     I think that principle would match all your rules if the 'mixed-revision' rule applies to working nodes but not base nodes.<<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 working version 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>>
+     [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] When I say 'working node' I mean the 'topmost' version of the node in the WC, no matter whether that is different from or the same as the base version.
+     [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.
@@ -86, +86 @@

  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.  Whenever an update occurs the cache(s) will be refreshed.
  
  The cache will be stored in a new wc-ng table:
- ||||||||||<tablewidth="978px" tableheight="324px"style="font-weight:bold;      ;text-align:center">TABLE: INHERITABLE_PROPS ||
+ ||||||||||<tablewidth="978px" tableheight="324px"style="font-weight:bold;       ;text-align:center">TABLE: INHERITABLE_PROPS ||
  ||<style="font-weight:bold;">Name ||<style="font-weight:bold;">Data Type ||<style="font-weight:bold;">Primary Key ||<style="font-weight:bold;">Foreign Key ||<style="font-weight:bold;">Notes ||
  ||wc_id ||integer ||Yes ||References NODES.WC_ID || ||
  ||local_relpath ||text ||Yes ||References NODES.LOCAL_RELPATH || ||