[Subversion Wiki] Update of InheritedProperties by pburba
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=diffrev1=52rev2=53
Comment:
Link to thread which spawned this effort.
Property inheritance provides a mechanism to find the versioned properties
set on the path-wise parents of a given path. Conversely it can be viewed as a
mechanism by which a versioned property set on a given path also applies to
that path's children.
=== 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'').
+ Desire for some form of inherited properties has existed almost from the dawn
of Subversion. This [[http://svn.haxx.se/dev/archive-2012-02/0207.shtml|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'').
=== What This Design Is and What It Isn't ===
This design provides the bare minimum to support the basics of inherited
properties:
[Subversion Wiki] Update of InheritedProperties by pburba
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=diffrev1=53rev2=54
Comment:
Mention SVN_RA_CAPABILITY_INHERITED_PROPS
apr_pool_t *result_pool,
apr_pool_t *scratch_pool);
}}}
+ === New Capabilities ===
+ {{{#!cplusplus
+ /**
+ * The capability to get inherited properties.
+ *
+ * @since New in 1.8.
+ */
+ #define SVN_RA_CAPABILITY_INHERITED_PROPS inherited-props
+ }}}
=== Drawbacks ===
The suggested design above has some known drawbacks and trade-offs:
[Subversion Wiki] Update of InheritedProperties by pburba
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=diffrev1=37rev2=38 Comment: Clarification of the 'Differentiating 'Inheritable' Vs. 'Normal' Properties' section. }}} == Design == === Differentiating 'Inheritable' Vs. 'Normal' Properties === - 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. + This is easy, there is no difference, there is no such thing as an inheritable property. Versioned properties, both Subversion's reserved properties and custom user properties, can be 'interpreted 'as inheritable, but otherwise function as they always have in terms of repository storage, setting properties, valid property names and values, etc.. + What is proposed here is a new way of looking at the familiar versioned property. The only differentiation that is important as far as the design is this: Is a property value 'inherited 'or 'explicit'? A path may have property 'PropName' explicitly set on it or property values may be inherited by a child path from some parent path(s) which also have 'PropName' explicitly set on them. === 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. @@ -93, +94 @@ 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=324pxstyle=font-weight:bold; ;text-align:centerTABLE: INHERITABLE_PROPS || + ||tablewidth=978px tableheight=324pxstyle=font-weight:bold; ;text-align:centerTABLE: 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 || ||
[Subversion Wiki] Update of InheritedProperties by pburba
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=diffrev1=38rev2=39 Comment: Expand authentication section and bump it after we talk about inheritance rules }}} == Design == === Differentiating 'Inheritable' Vs. 'Normal' Properties === + This is easy, there is no difference, there is no such thing as an inheritable property. Versioned properties, both Subversion's reserved properties and custom user properties, can be 'interpreted 'as inheritable, but otherwise function as they always have in terms of repository storage, setting properties, valid property names and values, etc.. What is proposed here is a new way of looking at the familiar versioned property. The only differentiation that is important as far as the design is this: Is a property value 'inherited 'or 'explicit'? A path may have property 'PropName' explicitly set on it or property values may be inherited by a child path from some parent path(s) which also have 'PropName' explicitly set on them. - This is easy, there is no difference, there is no such thing as an inheritable property. Versioned properties, both Subversion's reserved properties and custom user properties, can be 'interpreted 'as inheritable, but otherwise function as they always have in terms of repository storage, setting properties, valid property names and values, etc.. - What is proposed here is a new way of looking at the familiar versioned property. The only differentiation that is important as far as the design is this: Is a property value 'inherited 'or 'explicit'? A path may have property 'PropName' explicitly set on it or property values may be inherited by a child path from some parent path(s) which also have 'PropName' explicitly set on them. - - === 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 === . For a given property 'PropName': * A path may have 'PropName' '''explicitly''' set on it (i.e. exactly how versioned properties work today). ' ' + * 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). + * 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. @@ -84, +78 @@ [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. }}} + * 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
[Subversion Wiki] Update of InheritedProperties by pburba
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=diffrev1=39rev2=40 Comment: Break the 'inheritance rules' section into three, one general, one re the repos, and one re the WC (more to come on that last one). === Differentiating 'Inheritable' Vs. 'Normal' Properties === This is easy, there is no difference, there is no such thing as an inheritable property. Versioned properties, both Subversion's reserved properties and custom user properties, can be 'interpreted 'as inheritable, but otherwise function as they always have in terms of repository storage, setting properties, valid property names and values, etc.. What is proposed here is a new way of looking at the familiar versioned property. The only differentiation that is important as far as the design is this: Is a property value 'inherited 'or 'explicit'? A path may have property 'PropName' explicitly set on it or property values may be inherited by a child path from some parent path(s) which also have 'PropName' explicitly set on them. + === General Inheritance Rules === + A path (we'll refer to this as the 'child' path from here on) inherits a given property from any of the child's path-wise ancestors (the 'parent' paths) on which the given property is explicitly set. This means that a given path can inherit multiple values for a given property from different parents. Further, the child path may also have the given property explicitly set on itself. + This obviously differs from svn:mergeinfo, where inheritance only occurs when a child lacks explicit mergeinfo and only the nearest parent's mergeinfo is inherited. The new APIs will provide a list of parent paths/URLs and the properties inherited from each. It will be up to the caller, user, script, etc., to decide what it wants to do with this information. The goal here is maximum flexibility. It will be possible to implement a mergeinfo-like inheritance scheme or to merge multiple values together, again, whatever the consumer wants to do. + + === Repository Inheritance Rules === + Inheritance of properties within the repository is pretty straightforward, for a given property 'PropName': + + * A repository child_path@REV may inherit one or more values of the 'PropName' property from any of the child's parents (i.e. its path-wise ancestors @REV) which have the 'PropName' property explicitly set on them. + === Inheritance Rules === . For a given property 'PropName': - - * A path may have 'PropName' '''explicitly''' set on it (i.e. exactly how versioned properties work today). ' ' - - * 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). * 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. @@ -90, +95 @@ 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=324pxstyle=font-weight:bold; ;text-align:centerTABLE: INHERITABLE_PROPS || + ||tablewidth=978px tableheight=324pxstyle=font-weight:bold; ;text-align:centerTABLE: 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 || ||
[Subversion Wiki] Update of InheritedProperties by pburba
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=diffrev1=40rev2=41 Comment: Note another difference between our only inheritable prop to date and this generic implementation. This is easy, there is no difference, there is no such thing as an inheritable property. Versioned properties, both Subversion's reserved properties and custom user properties, can be 'interpreted 'as inheritable, but otherwise function as they always have in terms of repository storage, setting properties, valid property names and values, etc.. What is proposed here is a new way of looking at the familiar versioned property. The only differentiation that is important as far as the design is this: Is a property value 'inherited 'or 'explicit'? A path may have property 'PropName' explicitly set on it or property values may be inherited by a child path from some parent path(s) which also have 'PropName' explicitly set on them. === General Inheritance Rules === - A path (we'll refer to this as the 'child' path from here on) inherits a given property from any of the child's path-wise ancestors (the 'parent' paths) on which the given property is explicitly set. This means that a given path can inherit multiple values for a given property from different parents. Further, the child path may also have the given property explicitly set on itself. - This obviously differs from svn:mergeinfo, where inheritance only occurs when a child lacks explicit mergeinfo and only the nearest parent's mergeinfo is inherited. The new APIs will provide a list of parent paths/URLs and the properties inherited from each. It will be up to the caller, user, script, etc., to decide what it wants to do with this information. The goal here is maximum flexibility. It will be possible to implement a mergeinfo-like inheritance scheme or to merge multiple values together, again, whatever the consumer wants to do. + A path (we'll refer to this as the 'child' path from here on) inherits a given property from any of the child's path-wise ancestors (the 'parent' paths) on which the given property is explicitly set. This means that a given path can inherit multiple values for a given property from different parents. Further, the child path may also have the given property explicitly set on itself. This obviously differs from svn:mergeinfo, where inheritance only occurs when a child lacks explicit mergeinfo and only the nearest parent's mergeinfo is inherited[1]. The new APIs will provide a list of parent paths/URLs and the properties inherited from each. It will be up to the caller, user, script, etc., to decide what it wants to do with this information. The goal here is maximum flexibility. It will be possible to implement a mergeinfo-like inheritance scheme or to merge multiple values together, again, whatever the consumer wants to do. + + [1] Generic inherited properties also differ from mergeinfo in that the property value a child inherits from a parent is not based on the path-difference between the parent and child. The exact property value on the parent is the value the child will inherit. === Repository Inheritance Rules === Inheritance of properties within the repository is pretty straightforward, for a given property 'PropName': @@ -95, +96 @@ 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=324pxstyle=font-weight:bold; ;text-align:centerTABLE: INHERITABLE_PROPS || + ||tablewidth=978px tableheight=324pxstyle=font-weight:bold; ;text-align:centerTABLE: 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 || ||
[Subversion Wiki] Update of InheritedProperties by pburba
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=diffrev1=42rev2=43
Comment:
Rework the section on WC inheritance rules to reflect my latest thinking and
branch work.
* A repository child_path@REV may inherit one or more values of the
'PropName' property from any of the child's parents (i.e. its path-wise
ancestors @REV) which have the 'PropName' property explicitly set on them.
- === Inheritance Rules ===
+ === Working Copy Inheritance Rules ===
- . For a given property 'PropName':
+ . Inheritance within the working copy is a bit more complicated. For a given
property 'PropName' there are three basic cases of WC inheritance:
- * 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 '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
+ 1. If the peg and operative revisions [2] are for the path in question are
anything other than unspecified[3], then the respository is contacted to obtain
the path's inherited properties. This is analogous to the repository
inheritance model.
+ 1. If the peg and operative revisions are unspecified, then the working
copy child path inherits properties from its parents in the '''actual'''[4]
tree, up to nearest working copy root (this is termed '''default working copy
inheritance'''). Once the working copy root is reached, a WC child path may
also inherit properties from repository parents via the inherited properties
cache, which caches the properties inherited by the base node at the WC root
(see the
[[http://wiki.apache.org/subversion/InheritedProperties#Inherited_Properties_Cache|Inherited
Properties Cache]] section). Working copy roots here are defined as:
+* A directory whose parent directory is not a working copy.
+* A directory or file which is switched relative to its immediate parent.
+* The root of a directory external.
+* A file external.
+ These default WC inheritance rules have some important implications:
+
+ 1. A path, in an unmodified working copy at a uniform revision N, inherits
the same properties that the base of that path would inherit in the repository
at revision N.
+ 1. A path in a modified working copy effectively inherits properties from
the proto-revision that any modified WC represents (a set of changes that could
potentially be committed as a new revision).
+ 1. Mixed-revision working copies are similar to #2 except that there is no
proto-revision. So unlike svn:mergeinfo and like tsvn:auto-props, inheritance
across mixed-revision boundaries in the working copy is allowed by default.
+ Leaving Julian's questions for now...{{{#!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
I think that principle would match all your rules if the 'mixed-revision'
rule applies to actual nodes but not base nodes.BR
[1] This particular principle for how we treat the 'actual' tree 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] By 'actual' version I mean the 'topmost' (i.e. MAX(op_depth)) version
of the node in the WC, no matter whether that is different from or the same as
the base version.
}}}
- {{{#!wiki note
+ {{{#!wiki note
[PTB] JAF - I was envisioning a much simpler principle: Inheritance
within the WC is within the actual tree[1]. This is easy for a user to explain
and easy to understand. For example, no matter what the state of the WC a user
can always say,
[Subversion Wiki] Update of InheritedProperties by pburba
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=diffrev1=45rev2=46 Comment: Add a blurb on externals. 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. }}} - '### TBD: Externals: Do they work like switched subtrees?' - === 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. The cache will be stored in a new wc-ng table: - ||tablewidth=978px tableheight=324pxstyle=font-weight:bold; ;text-align:centerTABLE: INHERITABLE_PROPS || + ||tablewidth=978px tableheight=324pxstyle=font-weight:bold; ;text-align:centerTABLE: 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 || || @@ -109, +107 @@ + + === Externals === + Directory externals are treated as self-contained working copies with their own inherited properties cache. File externals, despite not being their own WC, are also treated as WC roots and get their own cache. The end result: Property inheritance '''never '''crosses external boundaries in the WC. === Authentication === The svn:mergeinfo property can be inherited by any child path the user has read access to, even if the user has no access to the parent path the svn:mergeinfo property is explicitly set on. Generic property inheritance is more restrictive:
[Subversion Wiki] Update of InheritedProperties by pburba
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=diffrev1=46rev2=47 Comment: Update the iprop cache section. }}} === 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. + 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. File externals will have their own cache as well. Whenever the WC is updated the cache(s) will be refreshed. + The cache will be stored in a new BLOB column in the NODES table called 'inherited_props'. If the node is the '''base''' node of a '''WC root''' then this column is populated with a serialized skel of the node's inherited properties. In all other cases it is NULL. - The cache will be stored in a new wc-ng table: - ||tablewidth=978px tableheight=324pxstyle=font-weight:bold; ;text-align:centerTABLE: 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 || || - ||op_depth ||integer ||Yes ||References NODES.OP_DEPTH || || - ||repos_parent_path ||text ||Yes ||-- ||Location of parent with one or more inheritable properties relative the the repository root. || - ||revision ||integer ||-- ||-- ||Revision of repos_parent_path. || - ||inheritable_props ||blob ||-- ||-- ||The parent's inheritable properties. || - - - === Externals === Directory externals are treated as self-contained working copies with their own inherited properties cache. File externals, despite not being their own WC, are also treated as WC roots and get their own cache. The end result: Property inheritance '''never '''crosses external boundaries in the WC.
[Subversion Wiki] Update of InheritedProperties by pburba
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=diffrev1=47rev2=48
Comment:
Update all new and revved APIs.
'nearest' - Shows the target's explicit properties and the nearest path-wise
parent for any properties which are *not* explicitly set on the target. This
would be useful for seeing inheritable properties which follow a strict
override model like svn:mergeinfo.
}}}
=== API Changes ===
- Rev svn_proplist_receiver_t to svn_proplist_receiver2_t, adding the argument
apr_hash_t *'''inherited_prop_hash'''. Also allow the possibility that the
existing apr_hash_t *prop_hash argument may be null:
+ Rev svn_proplist_receiver_t to svn_proplist_receiver2_t, adding the argument
apr_array_header_t *'''inherited_props'''. Also allow the possibility that the
existing apr_hash_t *prop_hash argument may be null:
{{{#!cplusplus
/**
* The callback invoked by svn_client_proplist4(). Each invocation
* provides the regular and/or inherited properties of @a path, which is
* either a working copy path or a URL. If @a prop_hash is not @c NULL, then
- * it maps explicit ttconst char */tt property names to ttsvn_string_t
*/tt
+ * it maps explicit ttconst char */tt property names to
- * explicit property values. If @a inherited_prop_hash is not @c NULL,
- * then it maps ttconst char */tt paths (either working copy paths or
- * URLs), which are parents of @a path, to a hash mapping ttconst char
*/tt
- * inherited property names to the ttsvn_string_t */tt explicit property
- * values found on these parents. Use @a pool for all temporary allocations.
+ * ttsvn_string_t */tt explicit property values. If @a inherited_props
+ * is not @c NULL, then it is a depth-first ordered array of
+ * #svn_prop_inherited_item_t * structures representing the
+ * properties inherited by @a path. Use @a scratch_pool for all temporary
+ * allocations.
*
* @since New in 1.8.
*/
@@ -273, +273 @@
void *baton,
const char *path,
apr_hash_t *prop_hash,
- apr_hash_t *inherited_prop_hash,
+ apr_array_header_t *inherited_props,
- apr_pool_t *pool);
+ apr_pool_t *scratch_pool);
}}}
{{{#!wiki note
[JAF] What do the keys of 'inherited_prop_hash' represent if 'path' is a
working copy path but some of the inherited properties are set on repository
paths that are above the WC root?
@@ -283, +283 @@
[PTB] JAF - It's a bit awkward, but I was thinking WC relative paths for
props inherited from WC parents and URLs for props inherited from the
repository (via the inherited prop cache). We obviously can't use WC keys in
all cases, but using URLs in all cases won't work either because a WC parent
might not exist in the repository due to local changes.
}}}
{{{#!wiki note
- [PTB] Instead of using a hash mapping parent paths to a hash of
properties, it probably makes more sense to use an array of structures which
contain the path/URL and the property hash as members. The array would be
sorted by the depth of the path/URL and would allow the caller to easily
determine the nearest parent of PATH if that is all that it needs (think of a
property with a svn:mergeinfo-like straight override model of inheritance where
all that ever matters is the nearest parent).
+ [PTB] Instead of using a hash mapping parent paths to a hash of
properties, it probably makes more sense to use an array of structures which
contain the path/URL and the property hash as members. The array would be
sorted by the depth of the path/URL and would allow the caller to easily
determine the nearest parent of PATH if that is all that it needs (think of a
property with a svn:mergeinfo-like straight override model of inheritance where
all that ever matters is the nearest parent). Done - change noted above.
}}}
- Rev svn_client_proplist3 to svn_client_proplist4, adding the argument
svn_boolean_t '''get_target_inherited_props''':
+ Rev svn_client_proplist3 to svn_client_proplist4, adding the argument
svn_boolean_t '''get_target_inherited_props''' as well as a scratch pool and
use the new svn_proplist_receiver2_t callback:
{{{#!cplusplus
/**
@@ -346, +346 @@
svn_proplist_receiver2_t receiver,
void *receiver_baton,
svn_client_ctx_t *ctx,
+ apr_pool_t *result_pool,
- apr_pool_t *pool);
+ apr_pool_t *scratch_pool);
}}}
- Rev svn_client_propget4 to svn_client_propget5, adding the argument
apr_hash_t **'''inherited_prop_hash''':
+ Rev svn_client_propget4 to svn_client_propget5, adding the argument
apr_array_header_t **'''inherited_props''':
{{{#!cplusplus
/**
@@ -357, +358 @@
* values are ttsvn_string_t */tt representing the property value for
* @a propname
[Subversion Wiki] Update of InheritedProperties by pburba
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=diffrev1=48rev2=49
Comment:
Delete a now inapplicable drawback
=== Drawbacks ===
The suggested design above has some known drawbacks and trade-offs:
- * [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.
* [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.
[Subversion Wiki] Update of InheritedProperties by pburba
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=diffrev1=51rev2=52
bax
}}}
{{{#!wiki note
+ The above examples apply only to the general case. Subversion reserved
properties that we deem inheritable may exhibit differing behavior, depending
on how we define inheritance merging for the property in question. For example,
might show either the explicit mergeinfo on or the mergeinfo existing on
nearest path-wise parent with explicit mergeinfo (or possible nothing if there
was no explicit mergeinfo on the target or its parents).
- The above examples apply only to the general case. Subversion reserved
properties that we deem inheritable may exhibit
- differing behavior, depending on how we define inheritance merging for the
property in question. For example,
- might show either the explicit mergeinfo on
- or the mergeinfo existing on
- nearest path-wise parent with explicit mergeinfo (or possible nothing if
there was no explicit mergeinfo on the target or its parents).
}}}
{{{#!wiki note
We may want to support different values for --show-inherited-props, possibly:
[Subversion Wiki] Update of InheritedProperties by pburba
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=diffrev1=31rev2=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
[Subversion Wiki] Update of InheritedProperties by pburba
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=diffrev1=32rev2=33 Comment: Clarification on limits of automatic merging of inherited props. 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=324pxstyle=font-weight:bold; ;text-align:centerTABLE: INHERITABLE_PROPS || + ||tablewidth=978px tableheight=324pxstyle=font-weight:bold; ;text-align:centerTABLE: 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 || || @@ -104, +104 @@ === 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. + This proposal purposefully avoids any concept of how inherited properties (possibly from multiple parents) 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. === Subcommand Changes === In general inherited properties will be treated like any other versioned property, so most subcommands will only notice the paths on which explicit properties are set, regardless of whether these are inheritable or not. For example, if we have an unmodified working copy and then make a local change to a parent path's explicit inheritable property:
[Subversion Wiki] Update of InheritedProperties by pburba
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=diffrev1=33rev2=34
Comment:
Adjust propget and proplist examples to reflect that any versioned property can
be inherited.
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=324pxstyle=font-weight:bold;
;text-align:centerTABLE: INHERITABLE_PROPS ||
+ ||tablewidth=978px tableheight=324pxstyle=font-weight:bold;
;text-align:centerTABLE: 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 || ||
@@ -107, +107 @@
This proposal purposefully avoids any concept of how inherited properties
(possibly from multiple parents) 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.
=== Subcommand Changes ===
- In general inherited properties will be treated like any other versioned
property, so most subcommands will only notice the paths on which explicit
properties are set, regardless of whether these are inheritable or not. For
example, if we have an unmodified working copy and then make a local change to
a parent path's explicit inheritable property:
+ Since inherited properties are really just a new way of looking at
versioned properties, most subcommands will only notice the paths on which
explicit properties are set. For example, if we have an unmodified working
copy and then make a local change to a parent path's explicit property:
* 'svn status' won't show any property mods on the parent's children paths.
* 'svn diff' will only show the property difference on the parent path.
@@ -119, +119 @@
* update (up): Updates the inherited properties cache(s).
* upgrade: Creates an empty inherited properties cache, but doesn't populate
it since that would require contacting the repository which upgrade shouldn't
need to do.
- Two subcommands, propget (pget, pg) and proplist (plist, pl), will support a
new option enabling users to find inherited properties on a path:
'--show-inherited-props'. When used, any inherited properties for the target of
the subcommand will be displayed. Inherited properties for subtrees of the
target are not shown. For example: Given this repository structure with the
explicit properties noted:
+ Two subcommands, propget (pget, pg) and proplist (plist, pl), will support a
new option enabling users to view inherited properties on a path:
'--show-inherited-props'. When used, any properties inherited by the target of
the subcommand will be displayed. Properties inherited by subtrees of the
target are not shown. For example: Given this repository structure with the
explicit properties noted:
{{{
- /svn:inheritable:foo=bar
+ /prop:foo=bar
- branch/ svn:inheritable:foo=bat, prop:baz=qux
+ branch/ prop:foo=bat
- branch/src/ svn:inheritable:foo=bax
+ branch/src/ prop:foo=bax
branch/src/pop.c
branch/inc
branch/inc/pop.h
@@ -139, +139 @@
{{{
svn pl -vR ^/branch
Properties on '%ROOT_URL%/branch':
- svn:inheritable:foo
+ prop:foo
bat
- prop:baz
- qux
Properties on '%ROOT_URL%/branch/src':
-
[Subversion Wiki] Update of InheritedProperties by pburba
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=diffrev1=27rev2=28
Comment:
Fix a typo - Too much mergeinfo on the brain.
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=324pxstyle=font-weight:bold;
;text-align:centerTABLE: INHERITABLE_PROPS ||
+ ||tablewidth=978px tableheight=324pxstyle=font-weight:bold;
;text-align:centerTABLE: 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 || ||
@@ -175, +175 @@
Properties on '%ROOT_URL%/branch/src':
svn:inheritable:foo
}}}
- A target with no explicit mergeinfo might still inherit a property from a
parent:
+ A target with no explicit inheritable properties might still inherit a
property from a parent:
{{{
svn pg -v --show-inherited-props svn:inheritable:foo ^/trunk
[Subversion Wiki] Update of InheritedProperties by pburba
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=diffrev1=23rev2=24 Comment: Update 'Merging Inherited Properties' section to agree with latest suggested APIs. 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=324pxstyle=font-weight:bold; ;text-align:centerTABLE: INHERITABLE_PROPS || + ||tablewidth=978px tableheight=324pxstyle=font-weight:bold; ;text-align:centerTABLE: 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 @@ 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 == - 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. + 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. == Subcommand Changes == In general inherited properties will be treated like any other versioned property, so most subcommands will only notice the paths on which explicit properties are set, regardless of whether these are inheritable or not. For example, if we have an unmodified working copy and then make a local change to a parent path's explicit inheritable property:
[Subversion Wiki] Update of InheritedProperties by pburba
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=diffrev1=24rev2=25
Comment:
Tweak the proposed svn propget and proplist changes so as to support a broader
range of inheritance models.
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=324pxstyle=font-weight:bold;
;text-align:centerTABLE: INHERITABLE_PROPS ||
+ ||tablewidth=978px tableheight=324pxstyle=font-weight:bold;
;text-align:centerTABLE: 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 || ||
@@ -117, +117 @@
* update (up): Updates the inherited properties cache(s).
* upgrade: Creates an empty inherited properties cache, but doesn't populate
it since that would require contacting the repository which upgrade shouldn't
need to do.
- Two subcommands, propget (pget, pg) and proplist (plist, pl), will support a
new option enabling users to find inherited properties on a path:
'--show-inherited-props'. When used, any inherited properties for the
'target' of the subcommand will be displayed. At operational depths
greater than empty however, the inherited mergeinfo subtree targets is not
shown. For example: Given this repository structure with the explicit
properties noted:
+ Two subcommands, propget (pget, pg) and proplist (plist, pl), will support a
new option enabling users to find inherited properties on a path:
'--show-inherited-props'. When used, any inherited properties for the target of
the subcommand will be displayed. Inherited properties for subtrees of the
target are not shown. For example: Given this repository structure with the
explicit properties noted:
{{{
- / svn:inheritable:foo=bar
+ /svn:inheritable:foo=bar
- branches/ svn:inheritable:baz=qux
+ branch/ svn:inheritable:foo=bat, prop:baz=qux
- branches/src/
+ branch/src/ svn:inheritable:foo=bax
- branches/src/foo.c
+ branch/src/pop.c
- branches/inc
+ branch/inc
- branches/inc/bar.h
+ branch/inc/pop.h
trunk/
trunk/src/
- trunk/src/foo.c
+ trunk/src/pop.c
trunk/inc
- trunk/inc/bar.h
+ trunk/inc/pop.h
}}}
Without the --show-inherited-props option only explicit properties are shown
(as has always been the case):
{{{
- svn pl -vR ^/branches
+ svn pl -vR ^/branch
- Properties on '%ROOT_URL%/branches':
+ Properties on '%ROOT_URL%/branch':
- svn:inheritable:baz
+ svn:inheritable:foo
+ bat
+ prop:baz
qux
+ Properties on '%ROOT_URL%/branch/src':
+ svn:inheritable:foo
+ bax
- svn pg -R svn:inheritable:baz ^/
+ svn pg -R svn:inheritable:foo ^/
+ %ROOT_URL% - bar
+ %ROOT_URL%/branch - bat
- %ROOT_URL%/branches - qux
+ %ROOT_URL%/branch/src - bax
- svn pg -v svn:inheritable:baz ^/trunk
+ svn pg -v svn:inheritable:foo ^/branch
- Properties on '%ROOT_URL%/branches':
+ Properties on '%ROOT_URL%/branch':
+ svn:inheritable:foo
+ bat
+
+ svn pg svn:inheritable:foo ^/trunk
+
+
+ }}}
+ With the --show-inherited-props option, explicit properties are shown as
normal, but any properties inherited by the target are also shown. For
example, a recursive propget on ^/branch shows the explicit properties on the
target and its children, but also shows that the target inherits
svn:inheritable:foo from the root of the repository:
+
+ {{{
+ svn pl -R --show-inherited-props ^/branch
+ Inheritable properties on '%ROOT_URL%':
+ svn:inheritable:foo
+ Properties on '%ROOT_URL%/branch':
+ svn:inheritable:foo
+ prop:baz
+ Properties on '%ROOT_URL%/branch/src':
+ svn:inheritable:foo
+ }}}
+ A target with no explicit mergeinfo might still inherit a property from a
parent:
+
+ {{{
+ svn pg -v --show-inherited-props svn:inheritable:foo ^/trunk
+ Inheritable properties on '%ROOT_URL%':
svn:inheritable:foo
bar
-
- svn pg svn:inheritable:baz
[Subversion Wiki] Update of InheritedProperties by pburba
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=diffrev1=21rev2=22
Comment:
A first stab at how to store the inherited props cache in a wc-ng table.
== 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.'
+ The cache will be stored in a new wc-ng table:
+ ||tablewidth=978px tableheight=324pxstyle=font-weight:bold;
;text-align:centerTABLE: 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 || ||
+ ||op_depth ||integer ||Yes ||References NODES.OP_DEPTH || ||
+ ||repos_parent_path ||text ||Yes ||-- ||Location of parent with one or more
inheritable properties relative the the repository root. ||
+ ||revision ||integer ||-- ||-- ||Revision of repos_parent_path. ||
+ ||inheritable_props ||blob ||-- ||-- ||The parent's inheritable properties. ||
+
+
+
+
+
== 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.
[Subversion Wiki] Update of InheritedProperties by pburba
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=diffrev1=15rev2=16
Comment:
Remove my rant/note about recursive inheritance. Looks like that is the
direction we are going in.
[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.
- . {{{#!wiki note
- [PTB] Even as I write #4, it occurs to me that once we elect to move beyond
a simple override model of inheritance (i.e. the mergeinfo model: a child
with an explicit inheritable property can't inherit that property) that we
begin descending the slippery slope into madness that has thwarted all previous
attempts at inherited properties. What if a child with the explicit
svn:inheritable:X property has a parent, and a grand parent, and a
great-grand-parent, etc. with the same explicit property but different values?
The new APIs below are only dealing with the first parent encountered, which is
pretty useless.
- }}}
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.
[Subversion Wiki] Update of InheritedProperties by pburba
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=diffrev1=16rev2=17
Comment:
Add some notes
{{{#!wiki note
[JAF] What do the keys of 'inherited_prop_hash' represent if 'path' is a
working copy path but some of the inherited properties are set on repository
paths that are above the WC root?
}}}
+ {{{#!wiki note
+ [PTB] JAF - It's a bit awkward, but I was thinking WC relative paths for
props inherited from WC parents and URLs for props inherited from the
repository (via the inherited prop cache). We obviously can't use WC keys in
all cases, but using URLs in all cases won't work either because a WC parent
might not exist in the repository due to local changes.
+ }}}
+ {{{#!wiki note
+ [PTB] Instead of using a hash mapping parent paths to a hash of
properties, it probably makes more sense to use an array of structures which
contain the path/URL and the property hash as members. The array would be
sorted by the depth of the path/URL and would allow the caller to easily
determine the nearest parent of PATH if that is all that it needs (think of a
property with a svn:mergeinfo-like straight override model of inheritance where
all that ever matters is the nearest parent).
+ }}}
+
Rev svn_client_proplist3 to svn_client_proplist4, adding the argument
svn_boolean_t '''get_target_inherited_props''':
{{{#!cplusplus
[Subversion Wiki] Update of InheritedProperties by pburba
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=diffrev1=17rev2=18
Comment:
Add a note re Julian's question about a unifying principle of intra-WC
inheritance.
[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.
}}}
+ {{{#!wiki note
+ [PTB] JAF - I was envisioning a much simpler principle: Inheritance
within the WC is within the actual tree[1]. This is easy for a user to explain
and easy to understand. For example, no matter what the state of the WC a user
can always say, I see that 'my-WC/trunk' has the inheritable property
'InhPropName=PropVal'. That means that 'my-WC/trunk/README' inherits
'InhPropName=PropVal'. That makes sense! If I understand correctly what you
suggest, a user could face the case where a child path inherits a property
value that differs from its actual WC parent's value (if it inherits anything
at all). That strikes me as a recipe for user confusion.
+
+ [1] By actual tree I mean the topmost (i.e. MAX(op_depth)) version of
the node in the WC, pretty much the same thing your 2nd footnote means(?). I
thought we differentiated actual vs. working such that the former included
property and text changes?
+ }}}
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.
@@ -192, +197 @@
{{{#!wiki note
[PTB] Instead of using a hash mapping parent paths to a hash of
properties, it probably makes more sense to use an array of structures which
contain the path/URL and the property hash as members. The array would be
sorted by the depth of the path/URL and would allow the caller to easily
determine the nearest parent of PATH if that is all that it needs (think of a
property with a svn:mergeinfo-like straight override model of inheritance where
all that ever matters is the nearest parent).
}}}
-
Rev svn_client_proplist3 to svn_client_proplist4, adding the argument
svn_boolean_t '''get_target_inherited_props''':
{{{#!cplusplus
[Subversion Wiki] Update of InheritedProperties by pburba
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=diffrev1=18rev2=19
Comment:
Create a 'Drawbacks' section to track the design's trade-offs. Move Daniel's
note into that section.
{{{#!wiki note
[JAF] Need to define the set of valid names and values. If they're in the
'svn:' namespace, then I imagine it needs to be (a subset of) the set of valid
'svn:' props -- mainly this means the values are UTF-8.
- }}}
- {{{#!wiki note
- [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 more flexible than the current svn:mergeinfo inheritance
model. For a given inheritable property 'svn:inheritable:X':
@@ -528, +525 @@
svn_boolean_t
svn_prop_is_inheritable_prop(const char *prop_name);
}}}
+ == Drawbacks ==
+ 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.
+
[Subversion Wiki] Update of InheritedProperties by pburba
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=diffrev1=19rev2=20
Comment:
Address a note: Document valid property names and values for inheritable
properties.
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.
- {{{#!wiki note
- [JAF] Need to define the set of valid names and values. If they're in the
'svn:' namespace, then I imagine it needs to be (a subset of) the set of valid
'svn:' props -- mainly this means the values are UTF-8.
- }}}
== Inheritance Rules ==
Inheritance will be more flexible than the current svn:mergeinfo inheritance
model. For a given inheritable property 'svn:inheritable:X':
[Subversion Wiki] Update of InheritedProperties by pburba
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=diffrev1=20rev2=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.
[Subversion Wiki] Update of InheritedProperties by pburba
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=diffrev1=11rev2=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
[Subversion Wiki] Update of InheritedProperties by pburba
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=diffrev1=12rev2=13
Comment:
A note regarding my slipping sanity.
[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.
+ . {{{#!wiki note
+ [PTB] Even as I write #4, it occurs to me that once we elect to move beyond
a simple override model of inheritance (i.e. the mergeinfo model: a child
with an explicit inheritable property can't inherit that property) that we
begin descending the slippery slope into madness that has thwarted all previous
attempts at inherited properties. What if a child with the explicit
svn:inheritable:X property has a parent, and a grand parent, and a
great-grand-parent, etc. with the same explicit property but different values?
The new APIs below are only dealing with the first parent encountered, which is
pretty useless.
+ }}}
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.
[Subversion Wiki] Update of InheritedProperties by pburba
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=diffrev1=13rev2=14
Comment:
Another tweak to the suggested APIs: Inherting from the nearest parent isn't
sufficient, need to account for *all* path-wise ancestors.
bar
}}}
== API Changes ==
- Rev svn_proplist_receiver_t to svn_proplist_receiver2_t, adding the argument
'''apr_hash_t *inherited_prop_hash'''. Also allow the possibility that the
existing apr_hash_t *prop_hash argument may be null:
+ Rev svn_proplist_receiver_t to svn_proplist_receiver2_t, adding the argument
apr_hash_t *'''inherited_prop_hash'''. Also allow the possibility that the
existing apr_hash_t *prop_hash argument may be null:
{{{#!cplusplus
/**
* The callback invoked by svn_client_proplist4(). Each invocation
- * provides the regular and/or inherited properties of @a path which
+ * provides the regular and/or inherited properties of @a path, which is
- * is either a WC path or a URL. If @a prop_hash is not null, then it
+ * either a working copy path or a URL. If @a prop_hash is not @c NULL, then
- * maps explicit property names (char *) to explicit property
- * values (svn_string_t *). If @a inherited_prop_hash is not null,
- * then it maps inherited property names (char *) to explicit property
+ * it maps explicit ttchar */tt property names to ttsvn_string_t */tt
+ * explicit property values. If @a inherited_prop_hash is not @c NULL,
+ * then it maps ttconst char */tt paths (either working copy paths or
+ * URLs), which are parents of @a path, to a hash mapping ttchar */tt
+ * inherited property names to the ttsvn_string_t */tt explicit property
- * values (svn_string_t *). Use @a pool for all temporary allocations.
+ * values found on these parents. Use @a pool for all temporary allocations.
*
* @since New in 1.8.
*/
@@ -223, +225 @@
*
* If @a get_target_inherited_props is true, then also return any inherited
* properties when @a receiver is called for @a target. If @a target is a
- * working copy path, then @a target may inherit properties up to the root
- * of the working copy. If no inherited properties are found up to the
- * root of the working copy, then check the inherited properties cache.
- * If @a target is a URL, then @a target may inherit properties up to the
- * root of the repository. If @a get_target_inherited_props is false, then
- * no inherited properties are returned to @a receiver.
+ * working copy path, then properties inherited by @a target as far as the
+ * root of the working copy are obtained from the working copy's actual
+ * property values. Properties inherited from above the working copy
+ * root come from the inherited properties cache. If @a target is a URL,
+ * then the inherited properties come from the repository.
+ * If @a get_target_inherited_props is false, then no inherited properties
+ * are returned to @a receiver.
*
* If @a target is not found, return the error #SVN_ERR_ENTRY_NOT_FOUND.
*
@@ -246, +249 @@
svn_client_ctx_t *ctx,
apr_pool_t *pool);
}}}
- Rev svn_client_propget4 to svn_client_propget5, adding the argument
'''svn_string_t **target_inherited_prop''':
+ Rev svn_client_propget4 to svn_client_propget5, adding the argument
apr_hash_t **'''inherited_prop_hash''':
{{{#!cplusplus
/**
* Set @a *props to a hash table whose keys are absolute paths or URLs
* of items on which property @a propname is explicitly set, and whose
- * values are `#svn_string_t *' representing the property value for
+ * values are ttsvn_string_t */tt representing the property value for
* @a propname at that path.
*
- * If @a target_inherited_prop is not null, then set
- * @a *target_inherited_prop to the value of @a propname which @a target
- * inherits from its nearest parent. If @a target is a working copy path,
- * then @a target may inherit properties up to the root of the working
- * copy. If no inherited properties are found up to the root of the
- * working copy, then the the inherited properties cache is checked.
- * If @a target is a URL, then @a target may inherit properties up to the
- * root of the repository. If no property is inherited, then set
- * @a *target_inherited_prop to null.
+ * If @a inherited_prop_hash is not @c NULL, then set @a *inherited_prop_hash
+ * to a mapping of ttconst char */tt paths (either absolute working copy
+ * paths or URLs) which are parents of @a target, to ttsvn_string_t */tt
+ * inheritable property values which are set on that parent. If @a target
+ * is a working copy path, then properties inherited by @a target as far as
the
+ * root of the working copy are obtained from the working copy's actual
+ * property values. Properties inherited from above the
[Subversion Wiki] Update of InheritedProperties by pburba
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=diffrev1=8rev2=9
Comment:
Don't require that Subversion reserved inheritable properties have any special
namespace beyond the standard svn: prefix.
Inheritable properties will be identified by a prefix on the property name.
1. Custom user properties will use the svn:inheritable: prefix.
- 1. Reserved Subversion inheritable properties will use the svn:i: 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.
{{{#!wiki note
[JAF] Need to define the set of valid names and values. If they're in the
'svn:' namespace, then I imagine it needs to be (a subset of) the set of valid
'svn:' props -- mainly this means the values are UTF-8.
[Subversion Wiki] Update of InheritedProperties by pburba
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=diffrev1=9rev2=10
Comment:
Remove svn:i: examples and replace with svn:inheritable:
[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:i:X':
+ Inheritance will be very similar to the current svn:mergeinfo inheritance
model. For a given inheritable property 'svn:inheritable:X':
- 1. A path 'with' svn:i: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 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:i: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:i:X'
property explicitly set on it (we'll refer to this as the 'parent' path).
+ 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 'working copy' child path 'without' the 'svn:i: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 '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.
* 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: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).
+ * 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).
{{{#!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
[Subversion Wiki] Update of InheritedProperties by pburba
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=diffrev1=10rev2=11
Comment:
Tweak suggested new APIs to allow retrieval of explicit and/or inherited
properties.
bar
}}}
== API Changes ==
- Rev svn_client_proplist3 to svn_client_proplist4, adding the svn_boolean_t
argument '''get_target_inherited_props''':
+ Rev svn_proplist_receiver_t to svn_proplist_receiver2_t, adding the argument
'''apr_hash_t *inherited_prop_hash'''. Also allow the possibility that the
existing apr_hash_t *prop_hash argument may be null:
+ {{{#!cplusplus
- '### TBD: Do we want to rev svn_proplist_receiver_t so it can
differentiate between explicit and inherited properties?'
-
- {{{
/**
+ * The callback invoked by svn_client_proplist4(). Each invocation
+ * provides the regular and/or inherited properties of @a path which
+ * is either a WC path or a URL. If @a prop_hash is not null, then it
+ * maps explicit property names (char *) to explicit property
+ * values (svn_string_t *). If @a inherited_prop_hash is not null,
+ * then it maps inherited property names (char *) to explicit property
+ * values (svn_string_t *). Use @a pool for all temporary allocations.
+ *
+ * @since New in 1.8.
+ */
+ typedef svn_error_t *(*svn_proplist_receiver2_t)(
+ void *baton,
+ const char *path,
+ apr_hash_t *prop_hash,
+ apr_hash_t *inherited_prop_hash,
+ apr_pool_t *pool);
+ }}}
+ Rev svn_client_proplist3 to svn_client_proplist4, adding the argument
svn_boolean_t '''get_target_inherited_props''':
+
+ {{{#!cplusplus
+ /**
- * Invoke @a receiver with @a receiver_baton to return the regular properties
+ * Invoke @a receiver with @a receiver_baton to return the regular explicit,
and
- * of @a target, a URL or working copy path. @a receiver will be called
- * for each path encountered.
+ * possibly the inherited, properties of @a target, a URL or working copy
path.
+ * @a receiver will be called for each path encountered.
*
* @a target is a WC path or a URL.
*
- * If @a revision-kind is #svn_opt_revision_unspecified, then get
+ * If @a revision-kind is #svn_opt_revision_unspecified, then get the
- * properties from the working copy, if @a target is a working copy
- * path, or from the repository head if @a target is a URL. Else get
- * the properties as of @a revision. The actual node revision
- * selected is determined by the path as it exists in @a peg_revision.
- * If @a peg_revision-kind is #svn_opt_revision_unspecified, then it
- * defaults to #svn_opt_revision_head for URLs or
+ * explicit (and possibly the inherited) properties from the working copy,
+ * if @a target is a working copy path, or from the repository head if
+ * @a target is a URL. Else get the properties as of @a revision.
+ * The actual node revision selected is determined by the path as it exists
+ * in @a peg_revision. If @a peg_revision-kind is
+ * #svn_opt_revision_unspecified, then it defaults to #svn_opt_revision_head
- * #svn_opt_revision_working for WC targets. Use the authentication
+ * for URLs or #svn_opt_revision_working for WC targets. Use the
- * baton cached in @a ctx for authentication if contacting the
+ * authentication baton cached in @a ctx for authentication if contacting
- * repository.
+ * the repository.
*
* If @a depth is #svn_depth_empty, list only the properties of
* @a target itself. If @a depth is #svn_depth_files, and
@@ -218, +237 @@
svn_depth_t depth,
const apr_array_header_t *changelists,
svn_boolean_t get_target_inherited_props,
- svn_proplist_receiver_t receiver,
+ svn_proplist_receiver2_t receiver,
void *receiver_baton,
svn_client_ctx_t *ctx,
apr_pool_t *pool);
}}}
- Rev svn_client_propget4 to svn_client_propget5, adding the svn_boolean_t
argument '''get_target_inherited_prop''':
+ Rev svn_client_propget4 to svn_client_propget5, adding the argument
'''svn_string_t **target_inherited_prop''':
- {{{
+ {{{#!cplusplus
/**
* Set @a *props to a hash table whose keys are absolute paths or URLs
- * of items on which property @a propname is set, and whose values are
+ * of items on which property @a propname is explicitly set, and whose
- * `#svn_string_t *' representing the property value for @a propname
+ * values are `#svn_string_t *' representing the property value for
- * at that path.
+ * @a propname at that path.
+ *
+ * If @a target_inherited_prop is not null, then set
+ * @a *target_inherited_prop to the value of @a propname which @a target
+ * inherits from its nearest parent. If @a target is a working copy path,
+ * then @a target may inherit properties
[Subversion Wiki] Update of InheritedProperties by pburba
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=diffrev1=6rev2=7
Comment:
Call out the proposed API changes.
{{{#!wiki note
[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:i:X':
@@ -75, +73 @@
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.
{{{#!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 ==
@@ -167, +164 @@
bar
}}}
== API Changes ==
- {{{#!wiki note
- [JAF] Please summarize the API changes.
- }}}
+ Rev svn_client_proplist3 to svn_client_proplist4, adding the svn_boolean_t
argument '''get_target_inherited_props''':
+
+ '### TBD: Do we want to rev svn_proplist_receiver_t so it can
differentiate between explicit and inherited properties?'
+
{{{
/**
* Invoke @a receiver with @a receiver_baton to return the regular properties
@@ -230, +228 @@
svn_client_ctx_t *ctx,
apr_pool_t *pool);
}}}
- '### TBD: Do we want to rev svn_proplist_receiver_t so it can
differentiate between explicit and inherited properties?'
+ Rev svn_client_propget4 to svn_client_propget5, adding the svn_boolean_t
argument '''get_target_inherited_prop''':
{{{
/**
@@ -306, +304 @@
svn_client_ctx_t *ctx,
apr_pool_t *result_pool,
apr_pool_t *scratch_pool);
+ }}}
+ Rev svn_ra_get_dir2 to svn_ra_get_dir3, adding the svn_boolean_t argument
'''get_inherited_props''':
+ {{{
/**
* If @a dirents is non @c NULL, set @a *dirents to contain all the entries
* of directory @a path at @a revision. The keys of @a dirents will be
@@ -347, +348 @@
apr_uint32_t dirent_fields,
svn_boolean_t get_inherited_props,
apr_pool_t *pool);
+ }}}
+ Rev svn_ra_get_file to svn_ra_get_file2, adding the svn_boolean_t argument
'''get_inherited_props''':
+ {{{
/**
* Fetch the contents and properties of file @a path at @a revision.
* @a revision may be SVN_INVALID_REVNUM, indicating that the HEAD
@@ -385, +389 @@
svn_revnum_t *fetched_rev,
apr_hash_t **props,
apr_pool_t *pool);
+ }}}
+ Rev svn_wc_prop_get2 to svn_wc_prop_get3, adding the svn_boolean_t argument
'''get_inherited_prop''':
+ '### TBD: Do we want another output argument to indicate if *VALUE is
inherited or not?'
+
+ {{{
/** Set @a *value to the value of property @a name for @a local_abspath,
* allocating @a *value in @a result_pool. If no such prop, set @a *value
* to @c NULL. @a name may be a regular or wc property; if it is an
@@ -412, +421 @@
svn_boolean_t get_inherited_prop,
apr_pool_t *result_pool,
[Subversion Wiki] Update of InheritedProperties by pburba
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=diffrev1=7rev2=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.
[Subversion Wiki] Update of InheritedProperties by pburba
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
Comment:
Initial brain dump on simple inherited properties
New page:
= INHERITED PROPERTIES : BACKGROUND =
== What's This? ==
Some ideas on how we might implement simple inherited properties.
== 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'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 Server Dictated Configuration (see
http://wiki.apache.org/subversion/ServerDictatedConfiguration and
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 pseduo-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'').
== 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.
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).
== 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.''
== Inheritable Properties Today ==
Subversion has supported merge-tracking using the svn:mergeinfo property since
the 1.5 release. The svn:mergeinfo property is inheritable in some
merge-sensitive contexts, notably 'svn merge', 'svn log -g', and 'svn
mergeinfo'. For example, say we have this simple branch structure at r700 in
our repository:
{{{
projX/
projX/branches/
projX/branches/src/
projX/branches/src/foo.c
projX/branches/inc
projX/branches/inc/bar.h
}}}
And suppose the mergeinfo 'projX/trunk:509-612' is set on 'projX/branches'. If
we perform a merge targeting 'projX/branches/src/foo.c', the merge logic
considers the svn:mergeinfo property on this target path to effectively be
'projX/trunk/src/foo.c:509-612'. However, unlike a true inheritable property
however, svn:mergeinfo is not inheritable outside of merge-tracking aware
contexts. For example, the propget and proplist subcommands recognize the
svn:mergeinfo when it is explicitly set on a path, but does not see it on
those paths' descendants:
{{{
svn pg svn:mergeinfo -v projX/branches Properties on 'projX/branches':
svn:mergeinfo
/projX/trunk:509-612
svn pg svn:mergeinfo -v branches/projX/src/foo.c
}}}
= INHERITED PROPERTIES : DESIGN =
== Differentiating Inheritable Vs. 'Normal' Properties ==
Inheritable properties will be identified by a prefix on the property name.
1. Custom user properties will use the svn:inheritable: prefix.
1. Reserved Subversion inheritable properties will use the svn:i: prefix.
== Inheritance Rules ==
Inheritance will be very similar to the current svn:mergeinfo inheritance
model. For a given inheritable property 'svn:i:X':
1. A path 'with' svn:i: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:i:X'
