On Sat, Jan 21, 2012 at 2:11 PM, Branko Čibej <brane_at_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
>
Received on 2012-01-23 18:17:30 CET