Branko Čibej wrote:
> 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.
>
I guess that I wasn't exactly clear at the beginning. This suggestion
was for doing the checkout/locking process that a lot of people were
wanting for future versions of svn.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Dec 20 04:07:04 2004