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.
