Hi all, First of all, thanks for working on server dictated config and inherited properties. We use Subversion as the core of a Document CMS (with focus on structured XML authoring). Some of the components we develop are available as open-source: http://repossearch.com/
We would be absolutely thrilled to see inherited properties implemented! There are many potential use cases for us, configuration of our services being one of the most imminent. Our primary input to this thread is that we would very much like inherited properties to be a generic feature accessible to other uses than core Subversion, preferably with API-support. On 28 jan 2012, at 10:30, Ivan Zhakov wrote: >> >> >> 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:). > While following the thread, I have debated this with myself over the last few days and each approach has advantages. Consumer inheritance (the property consumer decides which are inheritable) + Less effort to implement + No difficulty defining what makes a property inheritable - Access control issues/regression. Personally, I would be ok with a regression along the lines that a user with access further down the tree is allowed to read properties on the parent directories (the user already "knows about" them from the URL). The only users objecting to that regression are those that store secret information in properties on directories (rare?). The bigger problem is that it is counter-intuitive behaviour to disclose those properties. - Performance and difficulty for the consumer (but more flexibe). Defined inheritance (the server decides) - More effort to implement. - Needs a definition of which properties are inheritable. I would suggest a server config (regex perhaps) that defaults to matching "*:inherit:*", potentially limiting the first * to a single prefix (disallow ':'). If someone has used xyz:inherit:* the server can be configured more restrictively with "svn:inherit:*". - Less flexible with regards to different merging/override behaviour when property is defined on multiple directories. + Defined, and fairly intuitive access control behaviour. + Possibility to provide better APIs I am fine with either way, but I am swaying towards "defined inheritance" mainly because of the last item, "better APIs". Both the WC and the server could make it much simpler for the consumer to read and set inherited properties. Specifically, the server is in a much better position to efficiently (fewer round-trips) respond to proplist AND provide a single proplist containing both regular and inherited properties. /Thomas Å.
