On 1/15/14, 12:44 PM, Kyle Sluder wrote:
> Is there foreseeable benefit to moving them into the FS layer?
I can't think of any benefit other than a design that seems cleaner. I'm sure
Branko can though.
> To be completely explicit, the problem as I understand it is that since
> touching a file in the FS layer touches all its ancestors, implementing
> non-recursive locks in the FS layer would be problematic because
> touching an unlocked file might require touching a locked ancestor.
That's a theoretical problem of a theoretical fs implementation that doesn't
exist (and probably can't exist without Subversion 2.0). Branko's thinking
about that because he's been thinking about completely new FS implementations.
> How specifically does implementing locks in the RA layer sidestep the
> issue? Is it because the bubble-up semantics are confined to the FS
> layer, or is it because the RA layer can choose to bend the rules and
> say "yes, committing changes to /a/b/c bumps the revision of
> non-recursively-locked ancestor /a, but since there are no real
> modifications to that directory, I will allow this change"? Does this
> have any implications for higher levels of the stack—for example, would
> a DAV client be confused that a supposedly-locked collection has
> changed?
The fact that the bubble up happens is an implementation detail of the FS
layer. For instance, Branko actually has thought about a design without the
bubble up. The RA layer doesn't really know about that bubble up. It just
knows that you're touching /a/b/c, so it checks the lock state on that node
(and if we add recursive locks applying whatever sort of inheritance rules
apply to the locks that exist). I.E. it's checking the actual operations that
you're executing against the locks, not the side effects on the DAG.
DAV clients support a 0 depth (non-recursive) and an infinity depth. 0 depth
means only the collection itself is locked. Though that does include changing
the children of the collection since that's a property of the collection. So a
0 depth lock would not allow you to add or remove files from the collection,
but you could change the contents of files already present. Infinity depth is
fairly obvious, all children of the collection and their children and so on are
locked. If this is what we add support for I don't see any issues for DAV clients.
Clients can't presume that their locks can't be removed except by them since
the DAV spec says that servers may allow privileged users other than the lock
creator to remove locks:
http://webdav.org/specs/rfc4918.html#lock-creator
I suspect DAV clients in general don't ever try to use locks on directories
anyway since they we haven't ever had someone come along complaining that their
DAV client doesn't work with auto-versioning due to our lack of directory locks
(though I'll admit actual use of auto-versioning is pretty limited). So I'm
having a hard time envisioning a scenario with adding support for directory
locks (non-recursive or recursive) breaks them.
Received on 2014-01-15 22:17:26 CET