Re: versioning lock

Geoffrey M. Clemm (geoffrey.clemm@rational.com)
Tue, 14 Dec 1999 00:45:20 -0500 

Date: Tue, 14 Dec 1999 00:45:20 -0500
Message-Id: <9912140545.AA04797@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
In-Reply-To: <85256847.000D19EA.00@D51MTA03.pok.ibm.com> (ccjason@us.ibm.com)
Subject: Re: versioning lock

   From: ccjason@us.ibm.com

      So this is where versioning locks come into play.  A versioning
      lock (induced by any WebDAV lock that protects the locked URL)
      says that revision selection is computed and frozen for the duration
      of the lock for any versioned resource identified by any segment
      of the lock.  In the preceding example, this means that
      "//my-machine/ws/geoff" will select revision "//host/repo/vr/157/rev/5"
      for "//host/repo/vr/157" and revision "//host/repo/vr/197/rev/2"
      for "//host/repo/vr/197" for the duration of the lock, and ignore any
      movement of the label "foo" for those versioned resources.  When the
      lock is removed, normal dynamic revision selection becomes active.

   Sounds good.  Let's sniff around for possible complications.

   - It sounds like a single lock causes several resource to be "protected".
     This upward acting lock is a different than our downward acting depth
     locks.  A new animal and type of behavior to twist one's brain. Do we
     still want to call it a "lock"?

URL locks have always "protected" upwards as well.  You can't
modify certain aspects of the states of all the collections that
are named by prefixes of the locked URL.

   - My understanding is that revisions tend to be immutable.
     Would a lock like this prevent any modifications to those collections
     above?  Or would this somehow just protect specific bindings?

The versioning lock only prevents revision selection from being recomputed.
A collection above still can be changed by checking it out and then
checking it in, but only if these changes satisfy the URL lock.

   - Would the owner of the lock be exempted from the prevention of
     of versioning changes?

No, except by unlocking the resource and then locking it again.
We could have a special "recompute revision selection" method,
but I would defer doing so until we have sufficient experience
to be able to say this is really needed.

   - I take it the effect on a collection affected by multiple of these locks
     would be that the owner exemption mentioned above would only apply if the
     method invoked was invoked by the owner of ALL versioning locks
     affecting the collection.

No owner exemption, so no issue.

   - Might this lock work acceptably with the locking proposal you outlined
   this
     morning?  (More on that later after the rest of the locking list
     comments on that proposal.)

Yes.  Locking a URL that does not currently identify a resource presents
no problem for this scheme.

Cheers,
Geoff