Re: Locking in a versioning server

ccjason@us.ibm.com
Thu, 4 Nov 1999 23:15:41 -0500 

From: ccjason@us.ibm.com
To: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
cc: ietf-dav-versioning@w3.org
Message-ID: <85256820.00173636.00@D51MTA03.pok.ibm.com>
Date: Thu, 4 Nov 1999 23:15:41 -0500
Subject: Re: Locking in a versioning server



    ... Below it looks like
    they could use checkout and then do the lock.  But that certainly would
make
    a depth lock tedious if preceeded by lots of check outs.  And then many
of
    those would have to be followed by checkins or uncheckouts.  And in the
case
    of shared locks, those clients would have to cooperate to coordinate
the
    uncheckouts in an agreed fashion... unless we add something to the
server to
    automate all this for the client.

  A versioning client doesn't lock or checkout to achieve stability
  of their view ... they control the revision selection rule of their
  workspace.  So you only reserve (lock/checkout) a resource that you
  are about to change.

Um.  I forget the context of my statement, but it almost certainly was
suggesting
the checkout to prevent the lock from affecting other workspaces.  If there
is
another way to limit the lock to the current workspace, that would be fine.


    Caveat: I don't expect people to use shared write locks.  I do expect
them
    to use shared read locks when those are defined.

  Not versioning clients.  As above, they get their stability from control
  of the revision selection rule of their workspace, not by read-locking.

Umm.  Once again I forget the context of my statement, but if one is
sharing a workspace, it seems that shared read locks would be a good thing
to use even in a versioning client.  Especially if locks provide URI
locking
or remapping.  Perhaps you weren't suggesting otherwise though.

As for the locking preventing changes from coming in from
outside the workspace, it sounds like you've got that figured out and that
it's just a matter of picking the right rsr to achieve that.

I'm not clear what should happen with locks when one doesn't use one of
those protective rsr's though.  That is... I'm not sure the intent that
a client might have... unless perhaps they didn't know that the rsr wasn't
protective.   Ah.. that probably was the context of the above.  I probably
was trying to suggest a common semantic regardless of the rsr in place.

Anyway, I do think it's useful to be able to limit the scope of a lock to
the current workspace.   If it's necessary to do a checkout before hand to
do so, so be it... but as I said above, that would be tedious for a client
trying to create a depth lock.