Locking in a versioning server
jamsden@us.ibm.com
Tue, 19 Oct 1999 13:14:26 -0400
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <8525680F.005ECC99.00@d54mta03.raleigh.ibm.com>
Date: Tue, 19 Oct 1999 13:14:26 -0400
Subject: Locking in a versioning server
The following was taken, with minor updates, from the introduction section of
the versioning model document.
Locking Versioned Resources
Locking a versioned resource prevents any principal other than the owner of the
lock from checking out any revision in any activity. 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. Shared locks allow multiple
principals to control checkouts on the versioned resource or revision.
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.
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.
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.
Note, in all cases above, the semantics result from the inability of a principal
other than the lock owner to change the contents or properties of the locked
resource. The rules above are not new, they just highlight the interesting
semantics.