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.
Received on 2014-01-15 20:26:59 CET