[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: Paul Burba <ptburba_at_gmail.com>
Date: Fri, 27 Jan 2012 10:46:23 -0500

On Thu, Jan 26, 2012 at 5:22 PM, Daniel Shahaf <danielsh_at_elego.de> wrote:
> Paul Burba wrote on Thu, Jan 26, 2012 at 16:55:48 -0500:
>> On Tue, Jan 24, 2012 at 1:57 PM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
>> > 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.
>>
>> I'm not proposing anything like that...
>>
>> > We need to
>> > provide a way to set properties; we need to provide a way to get them (as
>> > efficiently as possible).
>>
>> Agreed.  Just the basics, that is all I am suggesting.
>>
>> > 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
>>
>> Ah, here is where I suspect we have a disconnect.  You say users can
>> choose "to interpret their own custom properties as inheritable".
>> This seemingly implies that there is no real difference between
>> "normal" user properties and "inheritable" user properties; it's all
>> in how we chose to interpret them.  Is this what you are saying?
>>
>> Because if it is, I think this is a mistake, as I've explained
>> elsethread.  I'll take another stab at explaining my objection:
>>
>> [It should be possible to read inheritable properties, but not other
>> properties, from the repository root even without read access to it.]

Hi Daniel,

Sure, the parent path might be the root of the repository, but not
necessarily. What you are stating above is only a specific example of
what I mean. I'm arguing for a more general principle:

    If you have read access to a path, then you can read the
    inheritable properties of that path's parents, regardless
    of what access you have to the parents.

>> Make sense?
>>
>
> Why can't the admin simply set the property on every project root?

Well we could, but what if a user doesn't have access to the project
root? We could step down to a deeper subtree level and set the
inheritable property. But how deep? To be sure the inheritable
property applies to all users, we'd need to consult the authz
configuration to be sure no user/path combination can't inherit the
property. That's not very convenient, so we could instead...

> Just like we, redundantly, set svn:ignore to the same value on all
> subversion/tests/libsvn_*/ directories.

...just set our property on *every* directory in the subtree we want
the "inheritable" property to apply to. But is that really an
"inheritable" property? Maybe in a very loose sense, but it doesn't
seem very useful.

Paul

> Daniel
>
> P.S. Sorry if my []-summarizing of your email is inaccurate.
Received on 2012-01-27 16:47:00 CET

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