Re: Locking in a versioning server

jamsden@us.ibm.com
Tue, 19 Oct 1999 14:36:11 -0400 

From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <8525680F.00663711.00@d54mta03.raleigh.ibm.com>
Date: Tue, 19 Oct 1999 14:36:11 -0400
Subject: Re: Locking in a versioning server







From: Jason Crawford on 10/19/99 01:58 PM

To:   jamsden@us.ibm.com
cc:   ietf-dav-versioning@w3.org

Subject:  Re: Locking in a versioning server  (Document link: Jim Amsden)



  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.
<jra>
Good point.
</jra>

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?
<jra>
Versioned resources are independent of workspaces. Workspaces only effect
working resources and revision selection.
</jra>


  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.
<jra>
Activities are resources created with MKRESOURCE. They have properties that are
effected as the result of checking things out and in in the context of the
activity. They provide information required for merging. They label segments of
the line of descent. They can have dependent activities (which are implicitly
included in workspace and merging operations). And they may have properties that
user can change with PROPPATCH.
</jra>


  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.
<jra>
Locking is not necessary to avoid update conflicts in different workspaces. Each
workspace will select a different working resource. Locking working resources is
only useful if two or more principles are using the SAME workspace. This may
often be the case when the default workspace is used.
</jra>