[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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
> 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).
Received on 2012-01-27 11:50:45 CET

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.