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=11&rev2=12 Comment: Adjust the 'Inheritance Rules' section to reflect the recent suggested API changes, i.e. a path can both have an explicit property and inherit the same property. [danielsh] Using the 'svn:inheritable:' namespace precludes a property from being both inheritable and ${some_future_semantics}, since a property name cannot be simultaneously in the 'svn:inheritable:' namespace and in the 'svn:{some_future_semantics}:' namespace. }}} == Inheritance Rules == - Inheritance will be very similar to the current svn:mergeinfo inheritance model. For a given inheritable property 'svn:inheritable:X': + Inheritance will be more flexible than the current svn:mergeinfo inheritance model. For a given inheritable property 'svn:inheritable:X': - 1. A path '''''with''''' svn:inheritable:X' explicitly set on it never inherits that property (i.e. a path can only inherit a property it doesn't have set on itself).''''' ''''' - 1. A repository path@REV '''''without''''' the 'svn:inheritable:X' property explicitly set on it (we'll refer to this as the 'child' path from here on) may inherit the 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). + 1. A path may have the svn:inheritable:X' '''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). - 1. A '''''working copy''''' child path '''''without''''' the 'svn:inheritable:X' property explicitly set on it may inherit the property from the path's nearest path-wise ancestor in the working copy. + 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. * 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. @@ -74, +74 @@ [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. }}} + 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. 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.
