[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [RFC] Inheritable Properties

From: Greg Stein <gstein_at_gmail.com>
Date: Mon, 6 Feb 2012 18:41:12 -0500

In most data storage mechanisms for the repository, inheritable
properties are a performance killer. Bill Tutt advised us against
inheritable properties years ago for exactly this reason. It is one of
the main reasons that we never implemented them. Good data modeling
for path-based inheritance is very difficult, and can put a lot of
constraints on your implementation. Bill noted that NTFS does not have
inheritable properties for perf reasons: instead, property changes
(notably, ACLs) are copied down to the N child, recursively, under the
altered node.

Consider any PATH -> DATA mapping for the storage. You now have to
decompose PATH into N segments and issue N-1 more queries to look for
inheritable properties.

I know that Hyrum is looking to use a key/value datastore in a future
FS backend. Inheritable properties could well make that project a
performance non-starter.


On Mon, Feb 6, 2012 at 18:15, Paul Burba <ptburba_at_gmail.com> wrote:
> 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
> 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
Received on 2012-02-07 00:41:48 CET

This is an archived mail posted to the Subversion Dev mailing list.