Re: UPDATE method and forking

(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? 

(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).

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.

Cheers,
Geoff



Werner Donné <werner.donne@re.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.donne@re.be
> >>
> 
> -- 
> Werner Donné  --  Re
> Engelbeekstraat 8
> B-3300 Tienen
> tel: (+32) 486 425803   e-mail: werner.donne@re.be