[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: Thu, 19 Jan 2012 12:11:33 -0500

On Tue, Jan 17, 2012 at 11:36 AM, Paul Burba <ptburba_at_gmail.com> wrote:
> On Mon, Jan 16, 2012 at 8:28 PM, Hyrum K Wright
> <hyrum.wright_at_wandisco.com> wrote:
>> On Mon, Jan 16, 2012 at 5:51 PM, Paul Burba <ptburba_at_gmail.com> wrote:
>> ...
>>> On Thu, Jan 5, 2012 at 4:52 PM, Hyrum K Wright
>>> <hyrum.wright_at_wandisco.com> wrote:
>>>> As I recall, there were a few reasons why inherited properties haven't
>>>> been implemented.  One is the client-side storage and lookup, which
>>>> wc-ng has helped with.  The other is what to do with non-checked out
>>>> parent directories, which you mention above.  Another problem is the
>>>> various authz issues, similar to the infamous issue 3242 problems we
>>>> had with copy and move.
>>> Maybe we can make a special case for inheritable properties, simply
>>> state that by definition, if you set an inheritable property on a
>>> path, then users, even those who don't have access to the path, but do
>>> have access to the path's children, can inherit the property.
>>> For example if a user has access to foo/bar/baz, then that user can
>>> inherit properties from foo, even if he doesn't have access to foo
>>> itself.  All the repository has to tell the client is, "Path
>>> foo/bar/baz inherted property NAME=VAL", it doesn't even need to say
>>> where it came from.
>>> If we don't make this exception then it seems to me that inheritable
>>> properties are dead in the water, at least as far as being a useful
>>> solution to "server" dictated auto-props and global-ignores.
>> After having gone through the wc-ng experience, alarm bells start
>> ringing every time somebody says "we can make a special case for ...".
> Hi Hyrum,
> I might have needlessly muddied the waters when I said "special case".
>  To be clear, I meant that *all* inheritable properties (not just
> "svn:auto-props" and "svn:global-ignores") would behave this way in
> the *general* case.
> The "special case" is not about "svn:auto-props" and
> "svn:global-ignores" in particular, but rather that we can know some
> information (i.e. the inherited property value) about a path-wise
> ancestor we don't have access to.
>>  Please, please, please consider if that's really needed, of if a more
>> generalizable solution is appropriate.
> Well if "that" is the ability of a path (which we have read access to)
> to know the inherited value of a property from the path's (path-wise)
> ancestor (which we have no access to), then yes, I think it is really
> needed.  Why?  Because without this behavior inheritable properties
> are crippled from the start.

I should also point out that the proposed behavior is exactly how our
only inheritable property to date (i.e. svn:mergeinfo) has been
treated since 1.5. That is, you can inherit mergeinfo from a path you
have no access to, as long as you have access to the path doing the

Received on 2012-01-19 18:12:07 CET

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