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=20&rev2=21 Comment: Move Julian's note about the limitations of absent/present properties to the 'Drawbacks' section. 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. - }}} '''''### TBD: Externals: Do they work like switched subtrees?''''' == Inherited Properties Cache == @@ -528, +525 @@ The suggested design above has some known drawbacks and trade-offs: 1. [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. + 1. [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.
