Re: UPDATE method and forking

Hi Werner,

> You have two alternatives for working in parallel, where one suffices. One
> method, working resources, exposes physical aspects such as forking and
> puts the resposibility for integrity at the client. The other is abstract.
> It doesn't expose implementation details, because each "branch" has its
> own VCR and the checked-in version of each VCR can be left to be the most
> recent version. The integrity responsibility is within the server.
>   
First of all, checking out a working resource _does_ create a new VCR, 
much like a VERSION-CONTROL request to an unmapped URL which is a member 
URL of a workspace, the main difference being that in the latter case 
the client can choose the URL. Both mechanisms can be used to create 
multiple VCRs sharing a common version history and both can (but not 
must) be used in the way you describe (letting the checked-in version of 
each VCR be the "end of a branch").
I am still trying to understand what you mean when you speak of 
'integrity'. Am I right that you propose, speaking loosely, that the 
'original' VCR should belong to something like a 'main branch', its 
checked-in version always being the end of that branch, and that a new 
branch should be created by creating a new VCR (based on an 'old 
version') within a workspace?
I you do so, feel free not to support the UPDATE feature in your 
implementation.

Regards,
Manfred

Received on Friday, 17 March 2006 14:57:16 UTC