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