Next message: Dan Kegel: "Three questions, and a paean to Perforce"
Date: Sat, 6 May 2000 17:41:43 -0400 (EDT)
Message-Id: <200005062141.RAA18417@tantalum.atria.com>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
Subject: Re: Locking revisions
From: "Tim Ellison/OTT/OTI" <Tim_Ellison@oti.com>
Taking out a lock on a URL whose target is a revision should be
allowed, but is a trivial case. The revision properties and
content are protected, so other clients cannot be making
conflicting changes.
A "lock" has two effects.
The first is that it ensures that the state of the resource cannot be
modified without the lock token. I agree that this is trivial for
revisions, since you can't modify the state anyway, with or without a
lock token.
The second is that it ensures that the lock token is required in order
to cause the locked URL to identify a different resource. In the case
of a stable URL, this is also trivial, since a client is not allowed
to change which revision is identified by a stable URL. But in case
of a URL that identifies a versioned resource, the association between
that URL and a revision can be changed with a SET-TARGET or CHECKIN
request. So a lock both ensures that without the lock token, you
can't associate the URL with a different versioned resource, and you
can't change the target.
Although there are mutable properties on a
revision, it does not make sense to prevent the server from
modifying these (i.e., failing merge requests etc.).
I agree. Locks only apply to dead properties (the only
dead properties defined in the versioning protocol are DAV:author
and DAV:comment).
Cheers,
Geoff