Re: Versioning and locking

Geoffrey M. Clemm (gclemm@tantalum.atria.com)
Sun, 23 May 1999 23:13:25 -0400 

Date: Sun, 23 May 1999 23:13:25 -0400
Message-Id: <9905240313.AA06604@tantalum>
From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: jamsden@us.ibm.com
Cc: ietf-dav-versioning@w3.org
In-Reply-To: <8525677A.00436644.00@d54mta03.raleigh.ibm.com>
Subject: Re: Versioning and locking


After some additional thought, I agree with the conclusion
(i.e. that locking a versioned-resource that selects a revision
should lock that revision, and locking a revision should prevent
checkouts from that revision).  I'd modify the rationale a bit
though.  In particular:

   From: jamsden@us.ibm.com

      Geoff says:

      My concern was that a non-versioning-aware client would issue a lock
      (just wanting that resource to not change), but if that resource was a
      versioned-resource that selects a revision,this lock would have a
      "create no successor" semantics, which is a much stronger statement
      than the non-versioning-aware client intended to make (it just didn't
      want the resource that it sees at that URL to change).

I'd now answer myself by saying "although stronger than what the client
intends, this is probably the simplest thing you can do to ensure that
this resource does not change (from the point of view of the locking client)".

   A non-versioning aware client locking a versioned resource would
   prevent anyone else from making any change to any revision of that
   versioned resource. But from the point of view of that client, that's
   what he wanted.

Preventing checkout from *any* revision of the versioned resource
would still be overkill ... preventing a checkout from the revision
selected by the versioned resource should be sufficient (that's
probably what you meant ?).

   I don't think we should get too hung up on supporting non-versioning
   aware clients. As long as we support access and minimal authoring, I
   think we will have met the spirit of down-level support. Allowing
   non-versioning aware clients to do versioning semantics through round
   about means will just add complexity to the protocol without making
   such access consistent with down-level clients.

In this particular case, I wasn't concerned about making versioning
semantics available to versioning-unaware clients, but rather I wanted
to avoid having reasonable actions by versioning-unaware clients
(like issuing a lock) having unreasonable affects on versioning-aware
clients.

Cheers,
Geoff