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