Re: Locking in a versioning server

Geoffrey M. Clemm (geoffrey.clemm@rational.com)
Wed, 3 Nov 1999 22:01:41 -0500 

Date: Wed, 3 Nov 1999 22:01:41 -0500
Message-Id: <9911040301.AA29969@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
In-Reply-To: <8525680F.005ECC99.00@d54mta03.raleigh.ibm.com>
Subject: Re: Locking in a versioning server

   From: jamsden@us.ibm.com

   The following was taken, with minor updates, from the introduction
   section of the versioning model document.

   Locking a versioned resource prevents any principal other than the
   owner of the lock from checking out any revision in any
   activity.

This semantics would result in a versioning-unaware client preventing
all development on that versioned resource in any workspace, even
though work in those other workspaces would not interfere with the
versioning-unaware client.  I think this is the wrong thing to do.

   Locking a revision of a versioned resource prevents any
   principal other than the owner of the lock from checking out just that
   revision in any activity.

This semantics would result in a versioning-unaware client
preventing all development of that resource in any workspace
that is currently selecting that revision, even though work
in those other workspaces would not interfere with the
versioning-unaware client.  I think this is the wrong thing to do.

   Shared locks allow multiple principals to
   control checkouts on the versioned resource or revision.

I don't think shared write locks serve much purpose in any
context, but I'll not belabor that point here (:-).

   Locking an activity prevents any principal other than the owner of the
   lock from making any further changes in the context of that
   activity. That is, it is not possible to checkout a resource using a
   locked activity.

This is fine with me.

   Locking a workspace prevents any principal other than the owner of the
   lock from making any change to that workspace including changing the
   revision selection rule, or checking out any resources in that
   workspace.

This is also fine with me.

   Locking a working resource prevents any principal other than the owner
   of the lock from making any change to that working resource. This is
   useful in cases where multiple principals share the same workspace,
   especially the default workspace.

As is this.

Cheers,
Geoff