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