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). 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 ... > 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
