[snipping the parts I concur with] Paul Burba wrote on Wed, Feb 08, 2012 at 17:08:57 -0500: > On Mon, Feb 6, 2012 at 7:20 PM, Daniel Shahaf <danie...@elego.de> wrote: > > Paul Burba wrote on Mon, Feb 06, 2012 at 18:15:11 -0500: > >> Hi All, > >> > >> There has long been a desire for Subversion to support some form of > >> inherited properties. Recently, while discussing a potential solution > >> for server dictated configurations (see > >> http://svn.haxx.se/dev/archive-2012-01/0032.shtml), the idea of using > >> inheritable properties as an alternative approach was raised. To that > >> end I put together an inherited properties design wiki, see > >> http://wiki.apache.org/subversion/InheritedProperties > >> > >> Many of you have already seen this wiki and weighed in on the server > >> dictated config thread, but in the event you haven't please check it > > > > I'm in that camp --- the threads were too long for me so I only followed > > them with one eye. Now that you called this RFC I reviewed the wiki > > proposal and made some comments below. > > > >> out. I'd like to move this forward or return to the original server > >> dictated config, so any questions, concerns, and/or suggestions are > >> greatly appreciated. > >> > >> Thanks, > >> > >> Paul > > > > - There's no mention on the wiki of _how_ inherited properties can help > > with server-dictated config. I realize it's probably somewhere in my > > mailbox, but a pointer would be useful. > > We've kicked around some ideas on the server dictated config thread > (http://svn.haxx.se/dev/archive-2012-01/0405.shtml). I've avoided > anything concrete mainly because if we can't agree on how to implement > *generic* inheritable properties (which is what this proposal is > about) then what's the point of describing a particular application? > And that is what this proposal is about: Generic inheritable
Agreed; but I looked in ServerDictatedConfiguration too for an inherited-props-based solution, and found none. Hence my question. > properties. How to differentiate them from regular versioned > properties, how to set them, and how to retrieve them. > > > - How does all this interact with 1.7-and-older clients? For example, > > if svn:inheritable:foo is set on ^/trunk and a 1.7 client propgets > > this property on a descendant of ^/trunk that doesn't have that > > property set, I presume that client would be told that that property > > doesn't exist on the descendant? > > Correct. You'll need a 1.8+ client and server to get the full benefit. > Not much different than merge tracking and svn:mergeinfo. If anybody > has any suggestions as to how a 1.7 client could suddenly recognize > inheritable properties, then I'm all ears! > First hunch: let's not open this rabbit hole. True, if someone does just 'propget' then we could do a server-side emulation.. but if that 'propget' is part of someone's reimplementation of libsvn_wc, we should probably not do any server-side overlays --- or trying to use that wc to change those props will, most likely, not end in the user-intended results. > > - "# Unlike svn:mergeinfo and like tsvn:auto-props, inheritance across > > mixed-revision boundaries in the working copy is allowed." > > > > Does this hold even if the nodes on either side of the mixed-revision > > boundary are not related? Like, for example, A/ and A/D/ at the end > > of the following example? --- > > As the proposal is currently written, yes, it would hold. So yes, A/D > in the WC below might inherit a different property value than ^/A/D@1. > Is this ideal? Hardly. But is it a serious problem? I'm not sure > it is. We can't commit any changes to A/D without updating. If we > copy D it will inherit properties from its new parent regardless. > Fair points. But it still seems a bit odd for a node to inherit props from a completely unrelated parent node. But I think you and Julian have this can of worms wide open, so I'll wait on the sidelines a bit on this issue. > Cheers, Daniel