Re: versioning lock
ccjason@us.ibm.com
Mon, 13 Dec 1999 21:21:38 -0500
From: ccjason@us.ibm.com
To: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
cc: ietf-dav-versioning@w3.org
Message-ID: <85256847.000D19EA.00@D51MTA03.pok.ibm.com>
Date: Mon, 13 Dec 1999 21:21:38 -0500
Subject: Re: versioning lock
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"?
- 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?
- Would the owner of the lock be exempted from the prevention of
of versioning changes?
- 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.
- 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.)