W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2006

Re: UPDATE method and forking

From: Werner Donné <werner.donne@re.be>
Date: Wed, 15 Mar 2006 14:31:46 +0100
Message-ID: <44181742.6080601@re.be>
To: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Cc: w3c-dist-auth@w3.org


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
Received on Wednesday, 15 March 2006 13:30:38 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:35 UTC