On Tue, Jan 17, 2012 at 11:36 AM, Paul Burba <ptbu...@gmail.com> wrote: > On Mon, Jan 16, 2012 at 8:28 PM, Hyrum K Wright > <hyrum.wri...@wandisco.com> wrote: >> On Mon, Jan 16, 2012 at 5:51 PM, Paul Burba <ptbu...@gmail.com> wrote: >> ... >>> On Thu, Jan 5, 2012 at 4:52 PM, Hyrum K Wright >>> <hyrum.wri...@wandisco.com> wrote: >>>> As I recall, there were a few reasons why inherited properties haven't >>>> been implemented. One is the client-side storage and lookup, which >>>> wc-ng has helped with. The other is what to do with non-checked out >>>> parent directories, which you mention above. Another problem is the >>>> various authz issues, similar to the infamous issue 3242 problems we >>>> had with copy and move. >>> >>> Maybe we can make a special case for inheritable properties, simply >>> state that by definition, if you set an inheritable property on a >>> path, then users, even those who don't have access to the path, but do >>> have access to the path's children, can inherit the property. >>> >>> For example if a user has access to foo/bar/baz, then that user can >>> inherit properties from foo, even if he doesn't have access to foo >>> itself. All the repository has to tell the client is, "Path >>> foo/bar/baz inherted property NAME=VAL", it doesn't even need to say >>> where it came from. >>> >>> If we don't make this exception then it seems to me that inheritable >>> properties are dead in the water, at least as far as being a useful >>> solution to "server" dictated auto-props and global-ignores. >> >> After having gone through the wc-ng experience, alarm bells start >> ringing every time somebody says "we can make a special case for ...". > > Hi Hyrum, > > I might have needlessly muddied the waters when I said "special case". > To be clear, I meant that *all* inheritable properties (not just > "svn:auto-props" and "svn:global-ignores") would behave this way in > the *general* case. > > The "special case" is not about "svn:auto-props" and > "svn:global-ignores" in particular, but rather that we can know some > information (i.e. the inherited property value) about a path-wise > ancestor we don't have access to. > >> Please, please, please consider if that's really needed, of if a more >> generalizable solution is appropriate. > > Well if "that" is the ability of a path (which we have read access to) > to know the inherited value of a property from the path's (path-wise) > ancestor (which we have no access to), then yes, I think it is really > needed. Why? Because without this behavior inheritable properties > are crippled from the start.
I should also point out that the proposed behavior is exactly how our only inheritable property to date (i.e. svn:mergeinfo) has been treated since 1.5. That is, you can inherit mergeinfo from a path you have no access to, as long as you have access to the path doing the inheriting. Paul