On Thu, Jan 19, 2012 at 03:23, Paul Burba <ptbu...@gmail.com> wrote: > 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. > Another option is make caller to know how to handle properties. I.e. introduce call like svn_get_inhertiable_prop(wc_path, propname) returning chain of configured properties with repos_path starting from given wc_path. For example call to svn_get_inheritable_prop("wcroot/foo/bar", "property") return: /repos/project/trunk/foo -> value1 /repos/project/trunk -> value2 /repos/ -> value3
Then caller may implement any logic to merge them. At implementation level we can store all properties and WC root (and for each switched root). -- Ivan Zhakov