On 1/15/14, 10:34 AM, Branko Čibej wrote: > We certainly have to hack thinks to map non-recursive directory locks to any > reasonable locking model in Subversion. This is because of Subversion's > bubble-up storage model, in which the revisions of all parent directories of a > change are updated by a commit.
I don't really see that as a problem at all. Locks are enforced at the RA layer. For instance in mod_dav's case the locks are actually enforced by mod_dav itself with it asking mod_dav_svn if there are any applicable locks. So the bubble up wouldn't even impact the current implementation if we extended it for directories. If we wanted to move the enforcement into the filesystems at some point, I guess that would become a complication, but until/unless we get rid of using mod_dav I think that's not going to be palatable. > Inheritance is also an interesting topic, and the fact that Subversion allows > locks to be created on nonexistent paths (and that our locks don't record the > recursive vs. non-recursive bit) would also make for interesting side effects. Non-existent paths for directories are less of an issue that you might think. The need for locking non-existent files (in generic DAV) is because PUT overwrites a file's content even if it already exists. So two users PUT'ing to the same location will end up having a race with only the last users content being preserved. The old DAV spec implemented this by using the whole lock null stuff where you don't actually create the file but the server keeps track that a lock null resource exists (clients can then pretend like the file exists or not depending on their preferences). Collections don't have this issue because you can't use MKCOL to overwrite an existing collection. You'd have to explicitly remove the existing directory. So in the case of two users both trying to create a collection, they'd race and the second one would fail due to the already existing collection. DAV when it was updated in 2007 deprecated this whole lock null nonsense and replaced it: http://webdav.org/specs/rfc4918.html#lock-null http://webdav.org/specs/rfc4918.html#lock-unmapped-urls As I read the spec, it seems to me that it is required that all LOCKS on non-existent (unmapped in DAV terminology) URLS are treated as file locks, and that creating a lock on a non-existing collection is not allowed. Since you don't NEED the lock on a non-existent directory due to the behavior of MKCOL I believe this makes sense. Additionally, we only allow locks on non-existent paths with auto-versioning, so our support here is to entirely work around the above. There's not even a UI confusion with a svn client since we disallow this behavior from them. One complication if we switch to the new LOCK model for DAV (LOCK actually creates empty files) is that a LOCK on an non-existent file would become a commit and a lock. I suspect we don't want to mess with that since the lock null resource implementation works fine and I don't think there's any need to switch in order to support directory locks, the model doesn't appear to be altered from the RFC 2518 spec. We'd need a format bump to add a depth field, but that doesn't seem to be a huge deal. It'd just be yet another repository controlled capability. Since all existing locks are file locks it's trivial to add the depth field (for that matter it's irrelevant what the depth field is because the behavior for all the values of depth for a file is the same). The biggest effort with respect to the storage is making it efficient to search for inherited locks. Right now create an index for locks but it can be flaky, in order for inherited locks to work well it'd have to be rock solid.