Re: UPDATE method and forking

If you don't want to use either workspaces or working resources,
then you would just use the base WebDAV functionality for handling
multiple clients concurrently updating the same resource, i.e. locking. 

So in your original sequence, just wrap the sequence in an LOCK/UNLOCK
pair, i.e.: 

LOCK the version-controlled resource
> - Retrieve the current checked-in version. (PROPFIND)
> - Set it to the most recent version in a "branch". (PROPFIND, UPDATE)
> - Perform a check-out or anything else that can be done on a version
>   controlled resource. (CHECKOUT, GET, PUT, CHECKIN)
> - Set the checked-in version back to what it was. (UPDATE)
UNLOCK the version-controlled resource.

Cheers,
Geoff

Werner wrote on 03/15/2006 08:31:46 AM:
> I'm not referring to working resources and I know that normally
> workspaces should be used to work in parallel. However, the
> workspaces feature is optional and the checkout-in-place feature
> doesn't depend on it. The checkout-in-place feature provides
> forking and therefore the model should be consistent in the
> absence of the workspaces feature.
> 
> According to me forking and workspaces are unrelated. The forking
> functionality stands on its own. When a fork is allowed for some
> version, it may have more than one successor. The only way to
> address a particular successor, for a check-out operation for example,
> is by setting the checked-in version of the VCR to it. This is a
> global state change.


> Geoffrey M Clemm wrote:
> > 
> > I believe you are confusing the "checkout-in-place" feature and
> > the "working-resource" feature. 
> > 
> > In the "checkout-in-place" feature, you make your changes
> > directly on the VCR.  If two clients want to be working
> > in parallel, they would have separate workspaces, and each
> > client would have its own VCR, so the VCR is not shared global
> > state, but rather is private state for the client that owns
> > that workspace.
> > 
> > In the "working-resource" feature, you do apply the
> > CHECKOUT directly to a version (see section 9.3), so again,
> > there is no mutable global state for which there would
> > be contention.
> > 
> > The only time in which there is shared mutable state is when
> > two clients are sharing the same workspace.  In this case,
> > the primary problem you face is the standard "lost update" problem
> > while you are authoring the content, and the solution is the
> > standard WebDAV solution: use the LOCK method.
> > 
> > Cheers,
> > Geoff
> > 
> > Werner wrote on 03/15/2006 04:30:19 AM:
> >>
> >> The UPDATE method can be used to set the checked-in version of a
> >> version controlled resource to a version which has descendants.
> >> At that point a check-out may fork, resulting in the checked-in
> >> version to have more than one descendant.
> >>
> >> This way a tree can be built. If one wants to grow the different
> >> branches of such a tree, the UPDATE method should be used to set
> >> the checked-in version of the version controlled resource
> >> appropriately. This, however, changes global state, which could
> >> lead to races.
> >>
> >> The complete operation the client would do is the following sequence:
> >> - Retrieve the current checked-in version of the version controlled
> > resource.
> >> - Set it to the most recent version in a "branch".
> >> - Perform a check-out or anything else that can be done on a version
> >>   controlled resource.
> >> - Set the checked-in version back to what it was.
> >>
> >> For this to work in a multi-user environment, either the sequence
> >> should be executed atomically and in isolation, or methods such as
> >> check-out should be allowed to operate on versions as well.
> 
> -- 
> Werner Donné  --  Re BVBA
> Engelbeekstraat 8
> B-3300 Tienen
> tel: (+32) 486 425803   e-mail: werner.donne@re.be
>