Subject: UPDATE method and forking

From: Werner Donné <[email-masked]>
Date: Wed, 15 Mar 2006 10:30:19 +0100

Hi,

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.

Regards,

Werner.
-- 
Werner Donné  --  Re BVBA
Engelbeekstraat 8
B-3300 Tienen
tel: (+32) 486 425803	e-mail: [email-masked]

---

From: Geoffrey M Clemm <[email-masked]>
Date: Wed, 15 Mar 2006 07:48:52 -0500

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

---

From: Werner Donné <[email-masked]>
Date: Wed, 15 Mar 2006 14:31:46 +0100

Geoff,

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.

Regards,

Werner.

---

From: Geoffrey M Clemm <[email-masked]>
Date: Wed, 15 Mar 2006 13:43:39 -0500

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)
>   controlled resource. (CHECKOUT, GET, PUT, CHECKIN)
> - Set the checked-in version back to what it was. (UPDATE)
UNLOCK the version-controlled resource.

Cheers,
Geoff

---

From: Werner Donné <[email-masked]>
Date: Thu, 16 Mar 2006 11:12:06 +0100

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.

-- 
Werner Donné  --  Re
Engelbeekstraat 8
B-3300 Tienen

---

From: Geoffrey M Clemm <[email-masked]>
Date: Thu, 16 Mar 2006 07:29:10 -0500

(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é <[email-masked]> wrote on 03/16/2006 05:12:06 AM:
> >> >> - Retrieve the current checked-in version of the version 
controlled
> >> > resource.

---

From: Werner Donné <[email-masked]>
Date: Thu, 16 Mar 2006 14:01:57 +0100

> why isn't it sufficient just to wrap the sequence of operations in

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.

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

> occurs as a side effect of parallel development, and not as a feature that

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.

Regards,

Werner.

---

From: Geoffrey M Clemm <[email-masked]>
Date: Thu, 16 Mar 2006 09:11:55 -0500

> keep the state consistent. That is a co-operative and hence unreliable

The only thing that can go wrong is that the client neglects to perform
an UNLOCK, which is why there are timeout and administrative override 
mechanisms
in the locking protocol.  But I agree that many clients would rather not 
deal with locks, which is why we introduced the workspace feature.  So 
lets
focus on whether or not the workspace feature provides what you need.

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

Well, to be honest, it is not at all clear to me what you do or do not
want to do (:-).  The purpose of the WebDAV model is provide a uniform
protocol for accessing the various authoring features provided by
a wide variety of repositories.  So the interesting questions are
"how do I as a client use the protocol to achieve this interesting
use case for a user" and "how do I as a repository use the protocol
to expose this particular feature of my repository to a client".
Without one of those questions in hand, one cannot have a productive
discussion about the WebDAV model.

> checked-in version, which is the source of the problem.

The way WebDAV (and HTTP) achieves interoperability is by having a client
use a single uniform protocol against a wide variety of servers.  So the
client always uses the UPDATE method to "restore" a version from history,
whether it is working with a server that supports working resources, 
supports
workspaces, supports both, or supports neither.  Changing the checked-in
version is important when the server supports either workspaces or
working resources, so you have clients uniformly use the UPDATE method.
This means that a client is aware of checkin-fork, checkout-fork, and
fork-ok behavior, so that in behaves properly when it is applied to a
server that supports either workspaces or working resources.

> Creating a new

No, it's part of the explicit user model, because when you invoke the 
MERGE
method, the result of the MERGE method is affected by whether or not there 
has
been any branching, so the client needs to understand when a branch will 
occur,
and when it won't. 

Cheers,
Geoff

---

From: Werner Donné <[email-masked]>
Date: Thu, 16 Mar 2006 18:34:45 +0100

Geoffrey M Clemm wrote:
> deal with locks, which is why we introduced the workspace feature.  So lets

Between each step in the sequence the dialogue can be interrupted. Not only
would the lock not be released, but the checked-in version of the VCR could
also be on another version than it was originally. This is an unexpected
global state change for all clients, which is not acceptable in a concurrent
system.

Regarding the lock release the timeout mechanism is not good enough if
locking is used like that, because VCR is blocked too long. This impacts
concurrency severely. When a transaction fails, for example, everything
is rolled back and release immediately.

Again, I'm not discussing what I need. I'm not a user.

> discussion about the WebDAV model.

I'm assessing the model, because I want to implement it. It is important
that a model is consistent and stable, otherwise its implementation will
be expensive. In my opinion exposing forking is not consistent. It is not
because there is another feature that does the trick, that a particular
feature shouldn't be scrutinised.

Inconsistent parts in a model have a life of their own and can have an
impact on other areas of the model during evolution, just for the sake
of compatibility.

> server that supports either workspaces or working resources.

It strikes me that workspaces don't expose forking, while working resources
do. Workspaces prove it is perfectly possible to offer branching and merging
without exposing an implementation artifact such as forking. Note that they
also make it possible to work transactionally within the repository without
exposing transaction demarcation.

Workspaces are well designed, while working resources are not. Their difference
should only about configurations, not in the way they offer branching. That
should be exactly the same. The two things are orthogonal.

> No, it's part of the explicit user model, because when you invoke the MERGE
> method, the result of the MERGE method is affected by whether or not
> there has

Merging and branching go together and you can do it with VCRs only. So there
is no reason to offer another user model for branching than that of workspaces.
Working resources should be made compatible with it.

Regards,

Werner.