[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Locking whole directories

From: Kyle Sluder <kyle_at_ksluder.com>
Date: Wed, 15 Jan 2014 12:44:58 -0800

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

--Kyle Sluder
Received on 2014-01-15 21:45:33 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.