Re: Exclusive Locking: 2nd draft

Greg Hudson <ghudson@MIT.EDU> writes:

> On Fri, 2004-05-21 at 12:17, Ben Collins-Sussman wrote:
> > That's it. Very simple. No special txns, no weird rules for reading.
> > Easy to implement in libsvn_fs for svn 1.1.
>
> Would locks be better implemented in libsvn_repos? (The commit
> restriction could be enforced by grabbing the changed-paths of the
> transaction and comparing them to the locks table list.)

I've always believed that locks are a detail of the repository, not of
a mostly generic versioned filesystem.

> Does anything special happen if you delete the path referred to by a
> lock, or a parent of it? If we ever get true renames, should anything
> special happen if you rename the path referred to by a lock, or a parent
> of it?

These are two topics I covered in my re-working of the original locks
design document (which I believe Ben posted to this list). You can't
delete a locked path (and therefore any of its parents) unless you
hold the lock for that path. If you try to delete a tree that has
many locked children, you must hold locks for *all* of those children.

You must hold the lock to rename a locked thing, and the lock follows
the object.

To date, I don't know if anyone has considered the ability to lock
directories -- I guess I can imagine it being useful as a shortcut for
locking many files, but I think it's probably overkill.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri May 21 18:43:35 2004