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
