Re: another idea for directory locking.

[Thomas Swan <ts...@idigx.com>]

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.

Thomas

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: another idea for directory locking.

[Branko Čibej <br...@xbc.nu>]

Thomas Swan wrote:

> Branko Čibej wrote:
>
>> 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.

No, that's quite clear. And it's those lock requests that don't block, 
and therefore can't deadlock.

-- Brane

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: another idea for directory locking.

[Thomas Swan <ts...@idigx.com>]

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

Re: another idea for directory locking.

[Branko Čibej <br...@xbc.nu>]

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