Thomas Swan wrote:
> When doing locks (or sets of locks), I would suggest doing the locks
> in a fixed order (predictable by client and server) to prevent
> deadlock. One suggestion is to acquire and release all of the locks
> in a depth first searching using an alphabetical ordering of
> directory/file names. This would help make the locking/unlocking more
> atomic and assert warnings if a specific lock could not be acquired.
>
> A depth first search would help prevent a lock on a directory if a
> child file or directory is already locked especially if the locks were
> done on the return of the directory traversal. This has the benefit
> of catching an existing lock before traversal, and preventing a lock
> if a child lock exists.
>
> The client can sort all of the locks it is asking for (in sorted
> order) by knowing its path, file list, or the requested path (on the
> server).
>
> If all of this has been beaten to death before, you have my apologies
> and please ignore the post.
It's not exactly been beaten to death, but mbk forgets that 'svn lock"
doesn't block until the lock is free, so deadlocks aren't an issue. If a
lock can't be obltained, simply roll back all locks that were granted
within the transaction.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 17 02:59:59 2004