On Thu, Jan 19, 2012 at 12:23 AM, Paul Burba <ptbu...@gmail.com> wrote: > On Tue, Jan 17, 2012 at 5:02 PM, Johan Corveleyn <jcor...@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