[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: Branko Čibej <brane_at_apache.org>
Date: Fri, 10 Feb 2012 12:21:02 +0100

On 07.02.2012 22:24, Stefan Fuhrmann wrote:
> On 07.02.2012 00:41, Greg Stein wrote:
>> In most data storage mechanisms for the repository, inheritable
>> properties are a performance killer.
>
> I'm not sure that this is actually applicable to SVN
> for two reasons:
> (1) we use deltification and

I have absolutely no idea how deltification helps with inheritable
properties.

> (2) we often handle whole file trees

Neither here nor there.

Inheritable properties would be /relatively/ less of a killer in SVN
backends because we're already doing lookups the silly way, i.e., a
lookup for /a/b/c will resolve and read /a and a/b while searching for
.../c, so it's not much extra work to keep the current values of
inheritable properties in the lookup context.

A proper lookup would jump straight to /a/b/c without examining the
intermediate directories, and /then/ it would have to climb back up the
tree to find inheritable props (or ACLs, same difference in this case).
For a real filesystem, that's definitely a performance killer, and the
reason why NTFS fakes ACL inheritance. The assumption is that you'll be
changing inheritable ACLs a lot less often than you will be reading
them, so the storage/performance tradeoff is definitely worth it.

I suspect the situation in SVN FS is quite similar, and if we
restructured the way the directory tree is represented to something
similar to how WC-NG (or Mercurial) does it, these issues would suddenly
become more important.

-- Brane
Received on 2012-02-10 12:21:44 CET

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.