You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Norbert Unterberg <ne...@gmx.net> on 2005/04/09 09:12:30 UTC

Question on lock behaviour

I have some questions regarding locking, I have not found the answeres 
in the locking GUI/implementation docs or release notes, so I'm asking here:

* Does locking depend on the svn:needs-lock property, or is locking 
allowed on all files, even if they do not carry the needs-lock property 
(giving a "locking is optional" behaviour)? If locking is optional, will 
locked files get the read-only attribute on an update if someone else 
has locked the file?

* Is it allowed to lock multiple files in one command, like
"svn lock *.bin"?
If yes, is this some kind of an atomic operation, meaning:
- same lock comment used for all files?
- repository lock-hook called once with a file list or once per file?
- no problem with concurrency when two users try the lock the same group 
of files at the same time.

* Does locking/unlocking a file without modifying the file require write 
access rights (in terms of mod_auth_svn)?

* Is it possible to lock a directory (i.e. with the effect of locking 
all files in that directory)?

Maybe someone creates a win32 binary of svn 1.2RC1, then I could try myself.

Thanks!


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

Re: Question on lock behaviour

Posted by Ben Collins-Sussman <su...@collab.net>.
On Apr 10, 2005, at 12:18 PM, Julian Foad wrote:
>
> That answer applies to each file individually, so the answer to 
> locking a group of files is that you may end up with some of the files 
> locked by one user and some by another.  That is, it is not atomic.
>
> (Is this true for all RA methods etc. or only some of them?  It's a 
> shame if we can't eventually make lock-group-of-files be an atomic 
> operation.)
>

It's true of all RA methods, because it's not related to RA at all.  
The svn_fs_lock() and _unlock() APIs only operate on one file at a 
time.

At the moment, however, svn_ra_(un)lock() takes a list of files, 
because in 1.3 we plan to marshall all of the paths over the network at 
once.  Once they arrive in libsvn_repos, svn_repos_fs_lock() will 
receive the list and pass the whole list to the pre- and post- (un)lock 
hooks.  But at the libsvn_fs level, the operations still happen 
per-file.


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

Re: Question on lock behaviour

Posted by Julian Foad <ju...@btopenworld.com>.
Ben Collins-Sussman wrote:
> On Apr 9, 2005, at 4:12 AM, Norbert Unterberg wrote:
>> * Is it allowed to lock multiple files in one command, like
>> "svn lock *.bin"?
> 
> Yes.
> 
>> If yes, is this some kind of an atomic operation, meaning:
> 
> It's not atomic as a group, each attempt to lock a file is a separate 
> event that could fail or succeed.
> 
>> - repository lock-hook called once with a file list or once per file?
> 
> At the moment, yes, but that will probably change in 1.3.  The new lock 

I think Ben means "At the moment, it is called once per file."

> hooks are designed to work on lists of files, but they're not being 
> invoked that way (yet.)
> 
>> - no problem with concurrency when two users try the lock the same 
>> group of files at the same time.
> 
> There is absolutely a race.  Someone gets the lock first, the other is 
> bounced out.  Just like commits.

That answer applies to each file individually, so the answer to locking a group 
of files is that you may end up with some of the files locked by one user and 
some by another.  That is, it is not atomic.

(Is this true for all RA methods etc. or only some of them?  It's a shame if we 
can't eventually make lock-group-of-files be an atomic operation.)

- Julian

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

Re: Question on lock behaviour

Posted by Ben Collins-Sussman <su...@collab.net>.
On Apr 9, 2005, at 4:12 AM, Norbert Unterberg wrote:

> I have some questions regarding locking, I have not found the answeres 
> in the locking GUI/implementation docs or release notes, so I'm asking 
> here:
>
> * Does locking depend on the svn:needs-lock property, or is locking 
> allowed on all files, even if they do not carry the needs-lock 
> property (giving a "locking is optional" behaviour)?

Locking is allowed on all files.  The needs-lock property is just an 
optional communication mechanism to encourage locking on certain files.


>  If locking is optional, will locked files get the read-only attribute 
> on an update if someone else has locked the file?

No.

>
> * Is it allowed to lock multiple files in one command, like
> "svn lock *.bin"?

Yes.


> If yes, is this some kind of an atomic operation, meaning:

It's not atomic as a group, each attempt to lock a file is a separate 
event that could fail or succeed.

> - same lock comment used for all files?

Yes.

> - repository lock-hook called once with a file list or once per file?

At the moment, yes, but that will probably change in 1.3.  The new lock 
hooks are designed to work on lists of files, but they're not being 
invoked that way (yet.)

> - no problem with concurrency when two users try the lock the same 
> group of files at the same time.

There is absolutely a race.  Someone gets the lock first, the other is 
bounced out.  Just like commits.

>
> * Does locking/unlocking a file without modifying the file require 
> write access rights (in terms of mod_auth_svn)?

Yes.


>
> * Is it possible to lock a directory (i.e. with the effect of locking 
> all files in that directory)?

No.


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