Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification.
The "InheritedProperties" page has been changed by pburba: http://wiki.apache.org/subversion/InheritedProperties?action=diff&rev1=6&rev2=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, apr_pool_t *scratch_pool); + }}} + Rev svn_fs_node_prop to svn_fs_node_prop2, adding the svn_boolean_t argument '''get_inherited_prop''': + {{{ - ### TBD: Do we want another output argument to indicate if *VALUE inherited or not? - /** Set @a *value_p to the value of the property named @a propname of * @a path in @a root. If the node has no property by that name and * @a get_inherited_prop is false, then set @a *value_p to zero. If @@ -433, +443 @@ const char *propname, svn_boolean_t get_inherited_prop, apr_pool_t *pool); + }}} + Rev svn_fs_node_proplist to svn_fs_node_proplist2, adding the svn_boolean_t argument '''get_inherited_props''': - + {{{ /** Set @a *table_p to the entire property list of @a path in @a root, * as an APR hash table allocated in @a pool. The resulting table maps * property names to pointers to #svn_string_t objects containing the
