[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: atomic locking

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2007-01-18 19:18:22 CET

Miller, Eric wrote:
> Is there a way to get svn_client_lock to do an all-or-nothing lock?

Nope. Locks aren't protected by atomicity guarantees outside what is
required to maintain the integrity of the backend storage. The
repository APIs only permit locking one path at a time, and no other
layer of interface between client and repository currently attempts to
corral multiple path-lock attempts under the umbrella of all-or-nothingness.

> Right now when it encounters an error during lock the function gives a
> warning but keeps locking.
> For instance:
> user1% svn lock a
> user2% svn lock a b
> svn: warning: Path '/trunk/a' is already locked by user 'user1 in
> filesystem '/svn/test/db'
> 'b' locked by user 'user2.
> Is this a bug or intended behavior? I can see this being useful for
> collections of binary data.
> Thanks,
> Eric

I don't recall whether it was intentionally implemented this way or not,
to be honest. I can certainly see the utility of an all-or-nothing set
of locks, and imagine it wouldn't be too terribly hard to implement as
much. New FS API svn_fs_lock_many(), new repos wrapper API()
svn_repos_fs_lock_many(), and I think our RA layer already support
sending multiple lock requests across the wire at once, so it would only
need a flag that turns on the "all-or-nothing guarantee", and then some
client-side UI to opt for that.

C. Michael Pilato <cmpilato@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on Thu Jan 18 19:18:44 2007

This is an archived mail posted to the Subversion Dev mailing list.