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=7&rev2=8 Comment: Consolidate copy section into inheritance rules }}} 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. {{{#!wiki note [JAF] I note that there is no ability to specify that an inheritable property should be '''''deleted''''' rather than overridden with a new value. Thus we can't use absent/present semantics similar to 'svn:needs-lock'. If we set an inheritable equivalent of 'svn:needs-lock = *' on a parent dir, there is no way to designate a particular child node as explicitly removing that inherited property. That's probably fine -- we can just avoid using the absent/present semantics for that kind of purpose -- but it deserves to be mentioned. @@ -92, +93 @@ == 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. - - == Copies and Inherited Properties == - {{{#!wiki note - [JAF] I suggest moving this section under the 'Inheritance Rules' section. - }}} - 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. == Merging Inherited Properties == It should be clear from reading this far that no concept of 'merging' inherited properties is proposed. If a path has an inheritable property set on it, then that property's value is the complete and full value for that path, end of story. Alternatively, if a path inherits a property, the inherited value is the complete and full value. Explicit and inherited property values will not be combined in any way. This means, for example, that if a child path inherits "svn:inheritable:someprop=SomeVal" from its parent, and you use 'svn propset' to set "svn:inheritable:someprop=NewVal" on the child path, then the latter is the new value for the child. The propset command doesn't care that you overrode the path's inherited property with an explicit one. It's easy to imagine use-cases where it is useful for a path's explicit and inherited properties to be merged, or for the inherited properties of a copy source to be merged with the copy destination's new inherited properties. But these depend on the purpose of the particular inherited properties. There is no way to develop a one-size-fits-all approach to merging inheritable properties, so any support for this needs to be special cased for the particular property in question.
