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
Received on 2014-01-15 21:45:33 CET