Re: Locking in a versioning server
Geoffrey M. Clemm (geoffrey.clemm@rational.com)
Thu, 4 Nov 1999 09:19:01 -0500
Date: Thu, 4 Nov 1999 09:19:01 -0500
Message-Id: <9911041419.AA00188@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
In-Reply-To: <8525680F.0073EE23.00@D51MTA03.pok.ibm.com> (ccjason@us.ibm.com)
Subject: Re: Locking in a versioning server
From: ccjason@us.ibm.com
... Below it looks like
they could use checkout and then do the lock. But that certainly would make
a depth lock tedious if preceeded by lots of check outs. And then many of
those would have to be followed by checkins or uncheckouts. And in the case
of shared locks, those clients would have to cooperate to coordinate the
uncheckouts in an agreed fashion... unless we add something to the server to
automate all this for the client.
A versioning client doesn't lock or checkout to achieve stability
of their view ... they control the revision selection rule of their
workspace. So you only reserve (lock/checkout) a resource that you
are about to change.
Caveat: I don't expect people to use shared write locks. I do expect them
to use shared read locks when those are defined.
Not versioning clients. As above, they get their stability from control
of the revision selection rule of their workspace, not by read-locking.
Question: If you lock a working resource and someone checks it in, what
happens?
I'd vote that it fails, but that's a good question and the answer should
be clearly stated in the spec.
Cheers,
Geoff