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 Tue, 11 Sep 2012 15:36:25 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=39&rev2=40

Comment:
Break the 'inheritance rules' section into three, one general, one re the repos, and one re
the WC (more to come on that last one).

  === Differentiating 'Inheritable' Vs. 'Normal' Properties ===
  This is easy, there is no difference, there is no such thing as an "inheritable" property.
Versioned properties, both Subversion's reserved properties and custom user properties, can
be '''''interpreted '''''as inheritable, but otherwise function as they always have in terms
of repository storage, setting properties, valid property names and values, etc.. What is
proposed here is a new way of looking at the familiar versioned property.  The only differentiation
that is important as far as the design is this: Is a property value '''''inherited '''''or
'''''explicit'''''?  A path may have  property 'PropName' explicitly set on it or property
values may be inherited by a child path from some parent path(s) which also have 'PropName'
explicitly set on them.
  
+ === General Inheritance Rules ===
+ A path (we'll refer to this as the 'child' path from here on) inherits a given property
from any of the child's path-wise ancestors (the 'parent' paths) on which the given property
is explicitly set.  This means that a given path can inherit multiple values for a given property
from different parents.  Further, the child path may also have the given property explicitly
set on itself.
+ This obviously differs from svn:mergeinfo, where inheritance only occurs when a child lacks
explicit mergeinfo and only the nearest parent's mergeinfo is inherited.  The new APIs will
provide a list of parent paths/URLs and the properties inherited from each. It will be up
to the caller, user, script, etc., to decide what it wants to do with this information.  The
goal here is maximum flexibility. It will be possible to implement a mergeinfo-like inheritance
scheme or to merge multiple values together, again, whatever the consumer wants to do.
+ 
+ === Repository Inheritance Rules ===
+ Inheritance of properties within the repository is pretty straightforward, for a given property
'PropName':
+ 
+  * A repository child_path@REV may inherit one or more values of the 'PropName' property
from any of the child's parents (i.e. its path-wise ancestors @REV) which have the 'PropName'
property explicitly set on them.
+ 
  === Inheritance Rules ===
   . For a given property 'PropName':
- 
-  * A path may have 'PropName' '''explicitly''' set on it (i.e. exactly how versioned properties
work today). ''''' '''''
- 
-  * A '''repository''' path@REV (we'll refer to this as the 'child' path from here on) may
inherit the value of the 'PropName' property from the path's nearest path-wise ancestor@REV
with the 'PropName' property explicitly set on it (we'll refer to this as the 'parent' path).
  
   * A '''working copy''' child path may inherit the 'PropName' property from the path's nearest
path-wise ancestor in the working copy.
    * For working copies with no switched subtrees, this inheritance can occur from any parent
path up to the root of the working copy.
@@ -90, +95 @@

  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 || ||

Mime
View raw message