subversion-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache subversion Wiki <comm...@subversion.apache.org>
Subject [Subversion Wiki] Update of "InheritedProperties" by pburba
Date Thu, 02 Feb 2012 17:59:06 GMT
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 pburba:
http://wiki.apache.org/subversion/InheritedProperties?action=diff&rev1=17&rev2=18

Comment:
Add a note re Julian's question about a unifying principle of intra-WC inheritance.

      [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>>
      [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.
  }}}
+   {{{#!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. 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.  There are no plans to provide an API which
reveals the specific parent path a child inherits from.
   1. While setting inheritable properties on a file has no meaning from the standpoint of
inheritance, the property still applies to the file itself.  Thus there will be no prohibitions
on setting inheritable properties on files.
@@ -192, +197 @@

  {{{#!wiki note
    [PTB] Instead of using a hash mapping parent "paths" to a hash of properties, it probably
makes more sense to use an array of structures which contain the path/URL and the property
hash as members.  The array would be sorted by the depth of the path/URL and would allow the
caller to easily determine the nearest parent of PATH if that is all that it needs (think
of a property with a svn:mergeinfo-like straight override model of inheritance where all that
ever matters is the nearest parent).
  }}}
- 
  Rev svn_client_proplist3 to svn_client_proplist4, adding the argument svn_boolean_t '''get_target_inherited_props''':
  
  {{{#!cplusplus

Mime
View raw message