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 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! > - "# New reserved Subversion properties may be introduced that are > inheritable by definition, but such properties are not required to use > any special namespace, beyond the normal "svn:" prefix." > > This implies a drawback: we add in 1.9 an svn:silver property and > declare it inheritable, then a 1.8 server won't recognize it as such. Ah, true. We'll need to go back to the original plan to have a separate namespace for Subversion reserved inheritable properties. > - "# 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. > [[[ > % $svn rm -q A > % $svn ci -q -m r2 > % $svn mkdir -q A > % $svn ci -q -m r3 > % $svn mkdir -q A/D > % $svn ci -q -m r4 > % cd A > % $svn up -r1 D > Updating 'D': > D D > A D > A D/gamma > ... > Updated to revision 1. > % > ]]] > > - "Whenever an update occurs the cache(s) will be refreshed." > > Suppose svn:keywords were inheritable and an update changed the cached > svn:keywords value in the parent of the wcroot. Would it be easy to > rewrite all files to the new keywords they now inherit? > > (I'm using svn:keywords as an illustration/example.) > > - INHERITABLE_PROPS schema > > Not a wc-ng expert, but would having a CONSTRAINT to the effect of > "Any (LOCAL_RELPATH, OP_DEPTH) tuple that appears in INHERITABLE_PROPS > must also appear (as a tuple) in NODES" be better than two FOREIGN KEY > constraints? Possibly yes, I'm not a wc-ng guru either, so feel ill-equipped to judge the merits of either approach. I fully plan to harass some wc-ng experts for help in this area, but not until we have more basic questions settled. > And two minor points: > > - "A target with no explicit mergeinfo might still inherit a property > from a parent:" > > How does mergeinfo factor in? (Typo?) Fixed that, I meant "explicit inherited property". > - Nitpick: svn_proplist_receiver2_t's docstring should use 'const char *' > for the types of hash keys. Fixed. > Cheers, > > Daniel
