Re: [RFC] Server Dictated Configuration
From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Fri, 27 Jan 2012 10:50:04 +0000 (GMT)
Paul Burba wrote:
> See http://wiki.apache.org/subversion/InheritedProperties for what I'm
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 }
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:
|
This is an archived mail posted to the Subversion Dev mailing list.
This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.