Re: Locking: Implementation Considerations

   From: ccjason@us.ibm.com

   <JC/> So in summary...  It is your opinion that the versioning work
   provides all of the (current) benefits of locking (presumably with a
   merge phase), but it is hard to implement so you offer the option of
   adding depth:0 locking.  Did I get that right?

<gmc> Yup.  I'd only modify that slightly to say it is *harder* to
implement versioning than depth:0 locking, but I wouldn't say it is
*hard* to implement versioning.

   <JC/> You mention a scenario where depth:0 locking is used in
   combination with versioning.  That suggests that you feel locking
   provides something that versioning doesn't....  is that the case?

<gmc/> Not quite.  In my opinion, locking is unneccessary if you
have versioning support, but I do care that locking clients interoperate
with versioning servers, so that is why I care about the combination
of locking and versioning.

   <gmc> (And thus he adroitly dodges the request to denigrate
   the versioning work :-).  </gmc>

   Cheater! :-) I think you or someone will have to answer this if we're
   to consider versioning to be a partial or true alternative to locking.
   Otherwise, we'll just have to evaluate your proposals to remove
   depthlock and null lock on each of their own merits.

<gmc>
Initially, lets just do the latter (i.e. evaluate the removal of
depthlock and null lock on their own merits).  I believe that Depth:0
locking is a good thing and stands on its own as worthwhile
functionality.  I believe Depth:infinity locking is a bad thing, both
for it's effect on clients trying to cooperate, and on servers trying
to implement the protocol in an interoperable way.

If we end up agreeing on those points, then we don't have to
spend the time/effort in discussing the incompatibility of
Depth:infinity with versioning, and the ways in which versioning
might provide a superior alternative to Depth:infinity locking.
<gmc/>

Cheers,
Geoff

Received on Friday, 20 August 1999 16:02:33 UTC