[An excerpt from my email to the dev@ list on this topic, found at http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1304305 See the full mail and resulting thread for details.] The Subversion security model is pretty simple. You have paths, you have the ability to say whether those paths are readable, writable, both, or neither by anyone or any-specific-one. The Subversion change transmission model is also pretty simple. You have the editor (svn_delta_editor_t) concept, which provides an interface for depth-first tree traversal, query, and modification. Finally, we have atomic commits. By themselves, these things are all Just Fine. When put together, we start to see problems. The binding of a single editor drive with the atomic commit concept for commits means that for a single commit, you must use a single editor drive to touch not just all the things you want to change in the commit, but all the parents of those things up to and including their longest common ancestor path. That becomes a problem when our security model's idea of "read access" is applied. [...] Now, we can point the finger at any number of places here. Some possibilies include: * Shame on the editor for requiring a depth-first tree drive that includes walking uninteresting parent directories. * Shame on the RA commit mechanism for binding an atomic commit operation to but a single editor drive. But here's where I think the real finger-pointing is best aimed: * Shame on the Subversion security model for not distinguishing between "you may know that PATH exists" and "you may see PATH's history, content and metadata".