UPDATE method and forking

Geoff,

I understand it can be done like that, but I have two
remarks:

1) Such a scenario should in fact be one transaction. The
proposed
   solution doesn't protect integrity. Currently the choice
is not
   to expose transaction demarcation to the client. That
implies
   the WebDAV model shouldn't expose scenarios which
require transactions
   either.

2) The locking mechanism in a versioning system is not
designed to
   implement transactional isolation. It is merely for
long-duration
   reservations of versions.

I agree that workspaces are the feature for working in
parallel, but
what is then the use of forking? Which problem does it
solve?

Regards,

Werner.

Geoffrey M Clemm wrote:
> 
> 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.donnere.be
>>

-- 
Werner Donné  --  Re
Engelbeekstraat 8
B-3300 Tienen
tel: (+32) 486 425803	e-mail: werner.donnere.be

Geoffrey M Clemm wrote:
> 
> (1) Why does this scenario have to be in one
transaction?  In particular,
> why isn't it sufficient just to wrap the sequence of
operations in
> a LOCK/UNLOCK?  

Because anything in between can go wrong, leaving the system
in an
inconsistent state. It can't be the responsibility of the
client to
keep the state consistent. That is a co-operative and hence
unreliable
design.

> 
> (2) I agree that the locking mechanism is not designed
to implement
> transactional isolation.  That is what workspaces and
working resources
> are designed for.  If (for unexplained reasons  you don't
want to
> use the versioning features that were designed for
transactional
> isolation, it should come as no surprise that you have
difficulty
> achieving transactional isolation.  Some clients don't
want/need
> transactional isolation (they just want history to be
kept, for example),
> which is why workspaces and working resources are
optional features
> (we define these two different ways of achieving
transactional isolation
> because some repositories can only support one, while
other repositories
> can only support the other, and we could find no way of
unifying these
> two different ways under a single feature).

This is obviously not at all about what I want or don't
want to use. I'm
reasoning about the WebDAV model. I haven't said I was
against workspaces.

> 
> As for the why support forking, it is an (undesireable,
but inevitable)
> side-effect of parallel development.  So we don't
define it as an
> independent feature, but we "deal with it"
for those features that
> support parallel development (i.e., workspaces and
working resources).
> In particular, it is what tells you that parallel
development has
> occurred on a particular resource, and that therefore a
merge is
> required (the need for a merge when forking occurs is
why it is
> "undesireable").
> 
> So creating forks in a non-parallel development context
makes no sense ...
> you are just making trouble for yourself.  Which is why
forking only
> occurs as a side effect of parallel development, and
not as a feature that
> you explicitly invoke.

Which is what I reckoned and it is an encapsulation flaw.
Clearly, forking
on its own is useless, but it is exposed through the WebDAV
interface with
elements such as "checkin-fork",
"checkout-fork", "fork-ok". There is
no
reason for this, nor for the UPDATE method to be allowed to
change the
checked-in version, which is the source of the problem.
Creating a new
VCR in a workspace from a given version obviously requires
forking, but
that is merely an internal implementation matter.

> 
> Cheers,
> Geoff
> 

Regards,

Werner.

> 
> 
> Werner Donné <werner.donnere.be> wrote on
03/16/2006 05:12:06 AM:
>> Geoff,
>>
>> I understand it can be done like that, but I have
two remarks:
>>
>> 1) Such a scenario should in fact be one
transaction. The proposed
>>    solution doesn't protect integrity. Currently
the choice is not
>>    to expose transaction demarcation to the client.
That implies
>>    the WebDAV model shouldn't expose scenarios
which require transactions
>>    either.
>>
>> 2) The locking mechanism in a versioning system is
not designed to
>>    implement transactional isolation. It is merely
for long-duration
>>    reservations of versions.
>>
>> I agree that workspaces are the feature for working
in parallel, but
>> what is then the use of forking? Which problem does
it solve?
>>
>> Regards,
>>
>> Werner.
>>
>> Geoffrey M Clemm wrote:
>> >
>> > 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.donnere.be
>> >>
>>
>> --
>> Werner Donné  --  Re
>> Engelbeekstraat 8
>> B-3300 Tienen
>> tel: (+32) 486 425803   e-mail: werner.donnere.be

-- 
Werner Donné  --  Re
Engelbeekstraat 8
B-3300 Tienen
tel: (+32) 486 425803	e-mail: werner.donnere.be