On Tue, Jan 17, 2012 at 5:02 PM, Johan Corveleyn <jcor...@gmail.com> wrote: > On Tue, Jan 17, 2012 at 8:55 PM, Paul Burba <ptbu...@gmail.com> wrote: >> On Tue, Jan 17, 2012 at 8:33 AM, Johan Corveleyn <jcor...@gmail.com> wrote: >>> On Tue, Jan 17, 2012 at 12:51 AM, Paul Burba <ptbu...@gmail.com> wrote: >>> >>> [...] >>> >>>> We could chose to make things simple and follow the svn:mergeinfo >>>> model of inheritance: >>>> >>>> a) If a path has an explicit given property then it doesn't inherit >>>> that property; the explicit value is the complete value. >>>> >>>> b) If a path doesn't explicitly have a given property then it inherits >>>> that property from its nearest parent with the property explicitly set >>>> on it. >>>> >>>> No merging of inherited with explicit properties, so no conflicts, >>>> just keep it simple. >>> >>> I'm just thinking out loud here, but what about the following approach: >>> >>> - These new svn properties (e.g. all properties in de 'svn:conf:' >>> namespace) are always *inheritable*. >>> >>> - But whether or not they are *inherited* (and in what way) is up to >>> the sub-tree. 'In what way': I'm thinking about inheritance vs. >>> extending/appending vs. override. >> >> Hi Johan, >> >> (The following may be the same as what you describe above, but just to >> be clear...) >> >> Let's keep in mind we (or at least I :-) have been talking about two >> closely related, but ultimately separate ideas: >> >> 1) Generic inherited properties >> 2) How to use inherited properties to facilitate repository-dictated >> auto-props and global-ignores. > > Agreed. Let's take repository dictated auto-props and global-ignores > as an example of inherited properties in general. > >> Viewed from the perspective of #1, a subtree either: >> >> a) Explicitly has a property set on it >> b) Doesn't have that explicit property but inherits it from a path-wise >> ancestor >> c) Doesn't have the the explicit property nor does it inherit it from >> any ancestor. > > Ok. But we can also dispense with c, as long as we're talking about > inheritable props: we could say that they are always inherited, no > matter what (except if you override them of course).
I was being a bit pedantic in c). I only meant that one possible state is that the property in question is literally not set *anywhere*. > 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... ...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. ~~~~~ 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?). 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 >> Those are the only three options. A subtree in the repository doesn't >> get to say whether or not in inherits a given property or not, either >> it does or does not by definition. Now as to what to *do* with this >> particular property... >> >> ...Once we start talking about #2 (or any other particular instance of >> an inheritable property), then we can imagine that different semantics >> come into play depending on the particular property and the context in >> which it is used. A subtree may inherit a given property, but what >> the client code decides to do with this value (ignore it, use it as >> is, merge it with something else, etc.) depends on context. >> >>> I'm thinking a bit along the lines of OO-languages: some special >>> syntax or keyword in the subtree's property signals that the property >>> must be inherited. >>> >>> Let's say we use '$super' to point to the inherited >>> prop, and if the prop is not specified, '=$super' is implied, then we >>> could do: >>> >>> ^/ -> svn:conf:ignore = *.o *.lo *.la *.al .libs >>> ^/native-app -> no prop needed ($super is implied) # >>> inherit >>> ^/native-app/python-mods -> svn:conf:ignore = $super *.pyc # append >>> ^/java-lib -> svn:conf:ignore = *.class # override >>> ^/java-lib/python-mods -> svn:conf:ignore = $super *.pyc # append >>> >>> Or something like that. >> >> Hmmm, maybe, but as I've mentioned elsewhere, it's these types of >> complexities that have kept inheritable properties from being >> implemented before now. I can readily vouch for the fact that the >> non-inheritable vs. inheritable concept used with svn:mergeinfo, while >> it works, is difficult for users to understand and has been the cause >> of many an edge case bug. So as far as *generic* inheritable >> properties go I still prefer the override-only model. > > 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, 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 :-). > > But anyway, starting out with an override-only system is perfectly > fine. If it fixes repository-dictated auto-props, it will make a lot > of svn admins (and users) very happy :-). It's still possible to add > some form of extendability later if and when it's deemed useful. > > Thanks for your work on this. > -- > Johan