On Wed, Jan 15, 2014, at 11:27 AM, Ben Reser wrote: > 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.
Is there foreseeable benefit to moving them into the FS layer? 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. 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? --Kyle Sluder
