Paul Burba wrote:
> See http://wiki.apache.org/subversion/InheritedProperties for what I'm
> envisioning.
I've added some notes to the Wiki page.
We need to see how we'd implement a reasonable system of svn:ignores and
auto-props using the proposed inheritable properties system. The ability to
see the inherited value and then merge in a child-defined value
(adding/subtracting/overriding semantic sub-elements within the property value)
is essential if we're going to implement these features using properties with
semantics like the existing 'svn:ignores'. To do that, we will need APIs that
can fetch the inherited value and the explicitly defined value for the same
path as two separate values, so that the client code can combine them according
to its own rules.
However, an alternative is to provide the required ('ignores' for example)
functionality in a way that matches the simple override semantics and does not
use the semantics of the original 'svn:ignores' property. For example, instead
of a multi-line value it could use a whole set of properties with one path
pattern encoded into each property name:
On ^/subversion/trunk: { svn:i:ignore:*.obj=True, svn:i:ignore:*.o=True }
On ^/subversion/trunk/bindings: { svn:i:ignore:*.pyc=True,
svn:i:ignore:*.o=False }
The total set of (inherited and explicit) inheritable ignore rules is thus
given by the total set of properties { svn:i:ignore-*.obj=True,
svn:i:ignore:*.o=False, svn:i:ignore:*.pyc=True }.
We could support both ways but I'm concerned that exposing both the inherited
and explicit versions of each property value may make the API semantics more
complex than necessary.
- Julian
>> Ivan Zhakov wrote:
>>> Another option is make caller to know how to handle properties. I.e.
>>> introduce call like svn_get_inhertiable_prop(wc_path, propname)
>>> returning chain of configured properties with repos_path starting from
>>> given wc_path. For example call to
>>> svn_get_inheritable_prop("wcroot/foo/bar", "property") return:
>>> /repos/project/trunk/foo -> value1
>>> /repos/project/trunk -> value2
>>> /repos/ -> value3
>>>
>>> Then caller may implement any logic to merge them. At implementation
>>> level we can store all properties and WC root (and for each switched
>>> root).
