On Mon, Jan 23, 2012 at 21:16, Paul Burba <ptbu...@gmail.com> wrote: > On Sat, Jan 21, 2012 at 9:05 AM, Ivan Zhakov <i...@visualsvn.com> wrote: >> 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). > > Hi Ivan, > > Are you suggesting that any property is inheritable simply by asking > it to be so? What we are talking about here is a way to differentiate > inheritable vs. non-inheritable properties (or as Johan put it: > "discern inheritable props from normal ones"). > Yes, that's exactly what I proposed. But I'm fine with idea differentiate properties behavior using dedicated namespaces (svn:i and svn:inheritable:).
-- Ivan Zhakov