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, 06 Mar 2012 17:05:11 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=31&rev2=32

Comment:
Start tweaking design so *any* versioned property can be inherited (if a user can at least
read the parent path).

- = Inherited Properties =
+ = Property Inheritance =
  == Background ==
  === What's This? ===
- Some ideas on how we might implement simple inherited properties.
+ Some ideas on how we might make versioned properties inheritable.
  
- === What Are Inherited Properties? ===
- Inherited properties are versioned properties that apply not only to the path the property
is explicitly set on, but also to all of that path's path-wise descendants (at the same revision)
which do not explicitly have the same property set.
+ === What Is Property Inheritance? ===
+ Property inheritance is a mechanism by which a versioned property set on a given path applies
also to that path's path-wise descendants.
  
  === What's Driving This? ===
  Desire for some form of inherited properties has existed almost from the dawn of Subversion.
 This latest effort is in response to a recent proposal regarding [[ServerDictatedConfiguration|Server
Dictated Configuration]] (see http://svn.haxx.se/dev/archive-2012-01/0032.shtml).  That proposal
made use of a new mechanism by which server dictated configurations (notably auto-props and
global-ignores) would be communicated from the server to the client.  In the feedback on the
proposal several people pointed out that versioned properties provide a possible alternative
solution (and that the TortoiseSVN project was already using pseudo-inheritable properties
to address some of the same problems -- see http://tortoisesvn.net/docs/nightly/TortoiseSVN_en/tsvn-dug-propertypage.html).
Despite its origins in the server defined configuration work, this wiki describes only a generic
inheritable properties design (''though my the ultimate goal is to use these inheritable properties
to implement the server dictated configuration feature -- pburba'').
@@ -14, +14 @@

  === What This Design Is and What It Isn't ===
  This design provides the bare minimum to support the basics of inherited properties:
  
-  * A way to identify properties that are inheritable vs. those that are not.
-  * A way to set inheritable properties (not really anything to do here, we support this
today).
-  * A way to get a path's inherited properties.
+  * A way to get a path's inherited properties from the repository.
+  * A way to cache a working copy's inherited properties locally so that disconnected WC
operations can remain disconnected.
  
- That's it, it's really just a small extension of our existing versioned property capabilities.
 If your own personal vision of inherited properties includes something outside of these three
bullets (e.g. merging inherited properties), then that is outside of this design's scope (at
least initially).
+ That's it, it's really just a small extension of our existing versioned property capabilities.
 Since any versioned property can be inherited, there is no concept of setting "inheritable"
properties.  Our existing APIs are sufficient.  If your own personal vision of inherited properties
includes something outside of these three bullets (e.g. merging inherited properties), then
that is outside of this design's scope (at least initially).
  
  === How Is This Design Different? ===
  It's not really.  A lot of the ideas here come from the dev list, #svn-dev, and conversations
with other devs.  The difference, if there is any, is that this design aims to be as simple
as possible and steer clear of complications which have thwarted inheritable properties in
the past. If there is more than one reasonable behavior to choose from, it usually goes with
the one that is simpler to explain/understand/implement/maintain.  ''This means that not everyone
will be happy, it may not cover every use-case, but I hope it covers most of them -- pburba.''
@@ -46, +45 @@

  >
  }}}
  == Design ==
- === Differentiating Inheritable Vs. 'Normal' Properties ===
+ === Differentiating 'Inheritable' Vs. 'Normal' Properties ===
- Inheritable properties will be identified by a prefix on the property name.
+ This is easy, there is no difference.  Versioned properties, both Subversion's reserved
properties and custom user properties, can be interpreted as inheritable, but otherwise will
function as they always have in terms of valid property names and values.
  
-  1. Custom user properties will use the "svn:inheritable:" prefix.
-  1. Existing Subversion reserved properties will '''''not''''' become inheritable, they
will function as they always have.  New reserved Subversion properties may be introduced that
are inheritable by definition, but such properties are not required to use any special namespace,
beyond the normal "svn:" prefix.
-  1. Valid property names for both custom user and Subversion reserved inheritable properties
are as per any other other versioned property (i.e. text only).
-  1. Valid property values for both custom user and Subversion reserved inheritable properties
are as per any other Subversion reserved property (i.e. text only and stored internally as
UTF-8).  This means that binary property values are not supported even in the case of custom
user properties.
+ === Authentication ===
+ The mergeinfo property can be inherited by any path the user has read access to,  even if
the user has no access to the parent path the inheritable  property is explicitly set on.
 Generic property inheritance will be more restrictive however: Properties can only be inherited
from paths which the user has read access to.
+ 
+ Yes, this means that an administrator could set up a restrictive authz configuration that
could thwart what might be desirable inheritance, e.g. very few users have read access to
the repository root, but a power user sets inheritable properties on the root intending that
they apply to the entire repos for all users.
+ 
+ ''We may allow exceptions for new Subversion reserved properties and let them behave in
a manner akin to svn:mergeinfo.''
  
  === Inheritance Rules ===
- Inheritance will be more flexible than the current svn:mergeinfo inheritance model.  For
a given inheritable property 'svn:inheritable:X':
+  . For a given property 'PropName':
  
-  1. A path may have the svn:inheritable:X' '''explicitly''' set on it (i.e. exactly how
versioned properties work today). ''''' '''''
+  * A path may have 'PropName' '''explicitly''' set on it (i.e. exactly how versioned properties
work today). ''''' '''''
-  1. A '''repository''' path@REV (we'll refer to this as the 'child' path from here on) may
inherit the value of the svn:inheritable:X property from the path's nearest path-wise ancestor@REV
with the 'svn:inheritable:X' property explicitly set on it (we'll refer to this as the 'parent'
path).
+  * 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).
-  1. A '''working copy''' child path may inherit the svn:inheritable:X property from the
path's nearest path-wise ancestor in the working copy.
+  * 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.
    * If the path is located within a switched subtree then the inheritance can occur up to
the root of the switched subtree.
    * Unlike svn:mergeinfo and like tsvn:auto-props, inheritance across mixed-revision boundaries
in the working copy is allowed.
-   * 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).
+   * If a working copy child path doesn't find a parent with 'PropName' 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 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>>
@@ -80, +81 @@

      [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.
  }}}
-  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.
+  * Note an important implication of #2 and #3: Unlike svn:mergeinfo, a child path with the
'PropName' property explicitly set on it can also inherit the 'PropName' 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.
+  * 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.
-  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.
-  1. If a child path which inherits a property is copied, the inherited  properties are not
copied with it.  The new destination path inherits  properties from its new parents.  This
means that depending on the copy  destination the new path may or may not inherit the same
property, and  even if it does, it may inherit a different value. This puts the onus on  users
to set their inheritable properties as close to the root of the  repository tree as makes
sense for the property in question.  Have a  property you want to apply to the whole repository?
 Set it on the root.   Want it to apply only to a single project?  Set it on the root of the
 project. Note that if a path has an inheritable property '''''explicitly''''' set on it,
the property is copied just like any other versioned property.
+  * If a child path which inherits a property is copied, the inherited  properties are not
copied with it.  The new destination path inherits  properties from its new parents.  This
means that depending on the copy  destination the new path may or may not inherit the same
property, and  even if it does, it may inherit a different value. This puts the onus on  users
to set their inheritable properties as close to the root of the  repository tree as makes
sense for the property in question (while considering any authorization restrictions that
might thwart inheritance).  Have a  property you want to apply to the whole repository?  Set
it on the root.   Want it to apply only to a single project?  Set it on the root of the  project.
Note that if a path has an inheritable property '''''explicitly''''' set on it, the property
is copied just like any other versioned property.
  
  '''''### TBD: Externals: Do they work like switched subtrees?'''''
  
@@ -91, +91 @@

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

  
  
  
- 
- === Authentication ===
- In exactly the same way that svn:mergeinfo is handled, generic inheritable properties can
be inherited by any path the user has read access to, even if the user has no access to the
parent path the inheritable property is explicitly set on.
  
  === 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.

Mime
View raw message