Re: versioning lock

Geoffrey M. Clemm (geoffrey.clemm@rational.com)
Sat, 11 Dec 1999 00:48:01 -0500 

Date: Sat, 11 Dec 1999 00:48:01 -0500
Message-Id: <9912110548.AA03577@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
In-Reply-To: <85256840.00125213.00@D51MTA03.pok.ibm.com> (ccjason@us.ibm.com)
Subject: Re: versioning lock

   From: ccjason@us.ibm.com

       Could you provide a concrete example with URI's.  I'm not sure
   I followed all of what you said.

Suppose I had a workspace "//my-machine/ws/geoff",
whose revision selection rule is "<rsr-label> foo </rsr-label>".
Suppose "//host/a" was bound to the versioned collection "//host/repo/vr/157".
Suppose revision "//host/repo/vr/157/rev/5" of "//host/repo/vr/157"
is labeled "foo".
Suppose "//host/repo/vr/157/rev/5" contains a binding of segment "b" to
the versioned resource "//host/repo/vr/197".
Suppose the revision "//host/repo/vr/197/rev/2" of "//host/repo/vr/197"
is labeled "foo".

This all implies that:
   GET //host/a/b
   Target-Selector: workspace "//my-machine/ws/geoff"
would return the body of "//host/repo/vr/197/rev/2".

Now suppose I requested:
   LOCK //host/a/b
   Target-Selector: workspace "//my-machine/ws/geoff"

This would imply that only the holder of the lock-token should be able
to make "//host/a/b" identify anything other than
"//host/repo/vr/197/rev/2".  But if anyone moved the label "foo"
from either "//host/repo/vr/157/rev/5" or "//host/repo/vr/197/rev/2",
then this lock could be violated, because the revision selection rule
would pick whatever revision was now labeled with foo.

But the workspace //my-machine/ws/geoff might not be
accessible when the move-label request was issued, so the server at
//host wouldn't know whether it could move the label or not.
Even if all workspaces were somehow known and accessible, it would
still be far too expensive to compute the effect of each metadata
modification (like a label move) against every workspace that has
a lock that might be affected by that modification.

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.

      Also note... to protect a URI in a conventional fashion, it sounds
   like a version lock would actually not lock the resource...

The term "the resource" is somewhat ambigous in this context, since
we have multiple versioned resources and multiple revisions that
are relevant.  In any case, a version lock doesn't lock the resource,
but rather freezes revision selection for the versioned resource
and any parent versioned collections.

   but a
   set of version locks would be used to lock the parentage of the
   resource.

Yes.

Cheers,
Geoff