Re: Locking in a versioning server

ccjason@us.ibm.com
Tue, 19 Oct 1999 13:58:56 -0400 

From: ccjason@us.ibm.com
To: jamsden@us.ibm.com
cc: ietf-dav-versioning@w3.org
Message-ID: <8525680F.0062699C.00@D51MTA03.pok.ibm.com>
Date: Tue, 19 Oct 1999 13:58:56 -0400
Subject: Re: Locking in a versioning server



  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.

Please qualify this by saying *write* locks.

Maybe you're forced to do what you just said... but shouldn't a lock on a
versioned resource just apply within the workspace?  Or is there some other
mechanism to protect who users of the workspace from stepping on each other
without affecting users outside the workspace?


  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.

Sanity check.  Activities are resources, right?  Activities can be created (and
destroyed?) but the activity itself can never be directly modified by client
methods like PROPPATCH, right?    (Sorry if it's a dumb question.  I only have
the spec to go by.)  It looks like required-activites might be user
modifiable... but then again, perhaps it's only set when the activity is
created.


  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.

OK.

  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.

Ah... so one would have to check out a resource and then lock the working
resource if they wanted to lock a resource within their workspace... but not
impact folks working outside their 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.

Owner(s)... plural.