On Fri, Jan 27, 2012 at 5:50 AM, Julian Foad <julianfoad_at_btopenworld.com> wrote:
> 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.
Hi Julian,
I'd like the inherited properties proposal to stand on it's own, but
since my first goal is to implement inheritable 'autoprops' and
'ignores' properties, I suppose it's fair enough to ask how it would
support those.
> 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'.
Why do we need to subtract and override? Why not stick with what we
have today, is there a strong user demand for more? What I mean
is...well let's back up first and look at what we have today:
1) The svn:ignore property set on directories and effecting only that
directory's immediate children.
2) The [miscellany] global-ignores configuration which affects the
entire working copy.
3) Right now (assuming a WC operation) the value of the svn:ignore
property (if any) on a path's parent directory is simply appended to
the global-ignores runtime config value to give the final answer on
what to ignore. Simple concatenation.
Now let's say we implement inheritable properties as I described in
the wiki and want to use an inheritable property to supplement the
existing mechanisms for svn:ignores/global-ignores. Isn't that as
simple as this?
4) We add a new reserved inheritable property svn:i:ignores which has
the exact same format as svn:ignore.
5) Again assuming a WC operation, we take a path's inherited (or
explicit) svn:i:ignores property value, the svn:ignore property (if
any) on a path's parent directory, and the global-ignores runtime
config value and append all three together to get the final answer on
what to ignore.
I take it you view this as insufficient?
> 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.
As Brane points out, simple using a different namespace for the
inheritable properties will accomplish this. No need to introduce the
concept of a path having both an explicit property 'X=VAL' while at
the same time inheriting property 'X=PARENT_VAL'.
Paul
> 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).
Received on 2012-01-27 22:38:40 CET