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 JulianFoad: http://wiki.apache.org/subversion/InheritedProperties?action=diff&rev1=3&rev2=4 Comment: Add notes about inheritance within a WC * 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:i: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). + {{{#!wiki note + [JAF] What is the unifying principle behind the set of rules? For example, a principle could be:<<BR>> + "Inheritance within a WC is based on inheritance within a single revision of the tree structure. Thus, a WC base node inherits from its repository parent in its repository revision, no matter whether that is present in the WC. The working version of the WC tree is treated as a single revision: an as yet unnumbered prototype for a revision that might be committed into the repository (or might not)[1]. Thus, a WC working node[2] inherits from the parent node that it would have in the repository if the current WC were committed in full."<<BR>> + I think that principle would match all your rules if the 'mixed-revision' rule applies to working nodes but not base nodes.<<BR>> + [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. 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. @@ -77, +84 @@ == Inherited Properties Cache == 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. + {{{#!wiki note + [JAF] The cache stores what semantic information? A mapping from (repo URL @ revision) to (inherited properties list), for each (repo URL @ revision) that occurs in the WC as a WC root or switched subtree root? + }}} '''''### TBD: Specifics for the wcng storage of these caches.''''' == 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 ==
