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. - 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? - "# 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. - "# 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? --- [[[ % $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? And two minor points: - "A target with no explicit mergeinfo might still inherit a property from a parent:" How does mergeinfo factor in? (Typo?) - Nitpick: svn_proplist_receiver2_t's docstring should use 'const char *' for the types of hash keys. Cheers, Daniel
