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=32&rev2=33

Comment:
Clarification on limits of automatic merging of inherited props.

  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 || ||
@@ -104, +104 @@

  
  
  === Merging Inherited Properties ===
- This proposal purposefully avoids any concept of how inherited properties 
might be merged together with explicit properties.  In some cases if a path has 
an inheritable property set on it, then it might make sense to consider that 
property's value as the complete and full value for that path, end of story 
(e.g. svn:mergeinfo).  On the other hand, it's easy to imagine use-cases where 
it might be useful to merge a path's explicit and inherited properties.  
However, both cases depend on the semantics of the particular inherited 
property. There is no way to develop a one-size-fits-all approach to merging 
inheritable properties.  So while the suggested API changes below support the 
ability to get a path's explicit and inherited properties, how to merge these 
values (if at all) will be handled on a case-by-case basis.
+ This proposal purposefully avoids any concept of how inherited properties 
(possibly from multiple parents) might be merged together with explicit 
properties.  In some cases if a path has an inheritable property set on it, 
then it might make sense to consider that property's value as the complete and 
full value for that path, end of story (e.g. svn:mergeinfo).  On the other 
hand, it's easy to imagine use-cases where it might be useful to merge a path's 
explicit and inherited properties.  However, both cases depend on the semantics 
of the particular inherited property. There is no way to develop a 
one-size-fits-all approach to merging inheritable properties.  So while the 
suggested API changes below support the ability to get a path's explicit and 
inherited properties, how to merge these values (if at all) will be handled on 
a case-by-case basis.
  
  === Subcommand Changes ===
  In general inherited properties will be treated like any other versioned 
property, so most subcommands will only notice the paths on which explicit 
properties are set, regardless of whether these are inheritable or not.  For 
example, if we have an unmodified working copy and then make a local change to 
a parent path's explicit inheritable property:

Reply via email to