Re: UPDATE method and forking

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.

Received on Wednesday, 15 March 2006 12:49:06 UTC