C. Michael Pilato wrote:
>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.
>
>
Yes, and the same is true of ACLs.
>>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.
>
>
+1
>You must hold the lock to rename a locked thing, and the lock follows
>the object.
>
>
That's not what the DAV spec says, but I agree it should be that way.
>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.
>
>
It's not overkill. Branches are directories, and a release manager may
want to lock a branch at certain ponts if they're using a relaxed
integration-merge policy.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat May 22 02:54:39 2004