Re: UPDATE method and forking

Werner Donné <werner.donne@re.be> wrote on 03/16/2006 08:01:57 AM:

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

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.

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

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.

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

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
> VCR in a workspace from a given version obviously requires forking, but
> that is merely an internal implementation matter.

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