Branko ??ibej wrote:
> Greg Stein wrote:
> >It may be that transactions are not needed either.
> >
> >
> We could probably avoid them, yes, but I'd prefer to keep the current
> transaction-per-lock design, so that we can support cooperating clients
> in the future. By "cooperating" I mean client processes that share a
> lock ID, or distinct clients that use a shared lock to make coordinated
I am not sure why associating a long-lived transaction with each lock
object helps you achieve these goals. I think that allowing multiple
clients to co-operate on an uncommitted transaction is an orthogonal
feature to locking, even shared locking. i.e. you should be able to
do one without the other and vice-versa.
Speaking of shared locking, is there some specific semantics for
shared locking that you're referring too? How would that work, a
client requests a lock and states that at most N other clients may
hold the lock at the same time? I was unable to find anything
resembling that in the WebDAV spec.
-Josh
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 20 18:10:45 2004