On Sat, Jan 21, 2012 at 2:11 PM, Branko Čibej <br...@apache.org> wrote: > On 17.01.2012 02:28, Hyrum K Wright wrote: >> ... and something like inheritable props my fit in that model, though >> I'd had to make the feature dependency tree another level deeper. > > Before you jump on the inheritable properties bandwagon, consider that > server-mandated configuration is not inherently versioned in the same > way as ordinary node properties (nor, for that matter, are ACLs). > > There is a valid case for allowing modification of server-side > configuration (and/or ACLs) for existing, historical revisions, which > you cannot do with node properties today. So these attributes behave > like revprops in the sense that you can change them for an historical > revision, but like node properties in the sense that they apply to a > path and/or subtree. It's a different-but-parallel structure to node > properties. > > You still want to maintain an audit trail of historic modifications, > however; so that you can ask, e.g., "what was the effective ACL of > ^/foo/bar two weeks ago and who changed it since then". This trail is, > by the way, something we don't provide for revprops, but should IMO. You > could say that revprops are just a special case of this attribute that > are constrained to the repository root.
Hi Brane, Valid points. An audit trail of configuration changes (particularly those that have a direct effect on the repository's contents, e.g. auto-props, global-ignores), is one of the advantages to "server-dictated-config-via-inheritable-versioned-props" approach over the one in http://wiki.apache.org/subversion/ServerDictatedConfiguration. And certainly a "versioned revprop" mechanism would have its uses. However I suspect that much of the former can be satisfactorily achieved without the latter...though I'm not 100% convinced by any proposed solution just yet[1]. Right now I'm working on a new wiki detailing a possible approach to generic inherited properties, separate from the question of server dictated configuration. If I'm going to bother with inheritable versioned properties to address some/all of server dictated config, then I want I want these inheritable properties to be generally useful (as opposed to our current inheritable property, svn:mergeinfo, which is obviously quite specialized and has no use outside of merge-tracking). Anyhow, I suppose all of the above is just a long-winded way of saying I'll keep your points in mind! Paul [1] I only have one foot on the inheritable properties bandwagon :-) > -- Brane >