[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: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Thu, 19 Jan 2012 01:56:27 +0100

On Thu, Jan 19, 2012 at 12:23 AM, Paul Burba <ptburba_at_gmail.com> wrote:
> On Tue, Jan 17, 2012 at 5:02 PM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:

[ ... ]

>> Which makes me wonder: how will we discern inheritable props from
>> normal ones? Merely saying that the svn:conf: namespace (for instance)
>> means that it's always inheritable, will not cut it if we're talking
>> about a generic feature ...
>
> 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.
>
> But for custom user properties? †Ugh, yet again I see why this feature
> has been avoided :-) †Either we declare that customer user properties
> names starting with some arbitrary string ("inherited:"?) will be
> treated as inherited or we require that inheritable properties be
> explicitly created as inheritable (i.e. some new option to propset and
> propedit). †The latter of course means we'll have to make changes to
> the backends and wcng to store this new trait. †The former means that
> we might make existing custom properties that share our chosen prefix
> into inheritable properties...

Hm, yeah. Going the "pure" route (adding an extra 'attribute' to
properties to make them inheritable) seems like a lot of work, and
additional complexity everywhere. So I guess going for some way of
leveraging the namespace would be the most realistic approach,
especially if you're aiming to tackle this for 1.8. It's a little less
clean, but if it's well defined ... it'll do the trick :-).

> ...Or maybe we invite users into our "svn:" namespace. †Let them use
> the "svn:inheritable:" prefix while we reserve the "svn:i:" prefix for
> our own use. †Seems like that would work.

Ah yes, good idea. That's an option if we want to avoid all risk of a
backwards compatibility breakage. (although your first suggestion,
reserving something like "inherited:", would also be acceptable I
think).

> ~~~~~
>
> I've also been pondering a closely related issue, namely how to
> differentiate between an explicitly set property and an inherited one.
> †What I mean is this, say we have this working copy:
>
> †branch-wc/
> †branch-wc/src/
> †branch-wc/src/main.c
>
> Further, let's suppose the inheritable property
> "svn:inherit:auto-props", with the value "*.c=svn:eol-style=native",
> is set on branch-wc/src. †If we ask what properties are on
> branch-wc/src the output is obvious:
>
> †>svn pl -v src
> †Properties on 'src':
> † †svn:inherit:auto-props
> † † †*.c=svn:eol-style=native
>
> Now if we ask what properties are found on src\main.c, we all (I
> hope!) expect to see both the properties explicitly set on main.c, as
> well as those inherited from src:
>
> †>svn pl -v src\main.c
> †Properties on 'src\main.c':
> † †svn:eol-style
> † † †native
> † †svn:inherit:auto-props
> † † †*.c=svn:eol-style=native
>
> But how does a user differentiate between an explicit and inherited
> property? †We'll need to flag it somehow. †For proplist this is
> relatively easy:
>
> †>svn pl -v src\main.c
> †Properties on 'src\main.c':
> † †svn:eol-style
> † † †native
> †Inherited properties on 'src\main.c':
> † †svn:inherit:auto-props
> † † †*.c=svn:eol-style=native
>
> †>svn pl src\main.c
> †Properties on 'src\main.c':
> † †svn:eol-style
> †Inherited properties on 'src\main.c':
> † †svn:inherit:auto-props
>
> But for propget it's a bit more difficult:
>
> †>svn pg svn:inherit:auto-props src
> †*.c=svn:eol-style=native
>
> †>svn pg svn:inherit:auto-props src\main.c
> †*.c=svn:eol-style=native
>
>
> Also, how does a --recursive propget or proplist work? †Does it show
> every path under src as having the "svn:inherit:auto-props" property?
> While that may be accurate, it's excessive. †We'd probably only want
> to show inherited properties on the root of the target path and let
> the rest be implied.
>
> Maybe the solution is that both propget and proplist don't show
> inherited properties by default, and only show them with a new option
> (--inherited?).

Hm, I think that would be best indeed. Perhaps --show-inherited. Still
not sure how that would affect recursive propget/proplist. But as you
say, maybe that's the least of the problems :-).

> Anyway, I don't want to beat this to death, if this is the least of
> the problems with inheritable properties I'll be happy.
>
> Paul
>

[ ... ]

>> I'm not sure if my suggestion implies the same kind of complexities as
>> with svn:mergeinfo. But then again, my involvement with subversion
>> pre-dates merge tracking,

Argh, it's a good thing that I reread my own ramblings now and then. I
meant to say "merge-tracking pre-dates my involvement with subversion"
of course. But you all knew that already :-).

>> so I'm not aware of all the discussions back
>> then, ideas that were tossed around, ... and I certainly don't have
>> the same battle-scars and experience with those things as (some of)
>> you have :-).

-- 
Johan
Received on 2012-01-19 01:57:23 CET

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