[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: C. Michael Pilato <cmpilato_at_collab.net>
Date: Tue, 24 Jan 2012 13:57:45 -0500

On 01/21/2012 09:05 AM, Ivan Zhakov wrote:
> On Thu, Jan 19, 2012 at 03:23, Paul Burba <ptburba_at_gmail.com> wrote:
>> Yeah, I've been thinking about this. As you say, the solution for our
>> "own" inheritable properties is simple. Since Subversion already
>> reserves properties beginning with "svn:" for its own use we could
>> just extend it and say anything beginning with "svn:inheritable:" is
>> inheritable.
> 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).

I must have blanked out through the sequence of emails that got us from
"let's solve a couple of oft-reported user issues regarding auto-props and
ignores" to "let's implement custom inherited properties". But in general,
I'm with Ivan here.

Subversion's behavior is unaffected by user-defined properties, so we have
zero obligation to implement any sort of advanced handling APIs that may or
may not ever be used in conjunction with those properties. We need to
provide a way to set properties; we need to provide a way to get them (as
efficiently as possible). The users can then do whatever they want with the
results, choosing to interpret their own custom properties as inheritable or
not based on criteria that is likewise custom, and performing the requisite
calculations for merging such properties using equally custom code around
our rather sufficient APIs.

Later, if sufficient user-generated demand -- based on real-world usage
scenarios -- for consistent handling/merging of properties which are, by
convention, deemed inheritable arise, we can explore adding public APIs to
consistify this handling/merging. But please, let's not overdesign this for
the sake of "what if".

C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on 2012-01-24 19:58:26 CET

This is an archived mail posted to the Subversion Dev mailing list.