Re: Version issues

Jim Whitehead (ejw@ics.uci.edu)
Thu, 1 Apr 1999 16:59:05 -0800 

From: Jim Whitehead <ejw@ics.uci.edu>
To: Versioning <ietf-dav-versioning@w3.org>
Date: Thu, 1 Apr 1999 16:59:05 -0800
Message-ID: <003a01be7ca4$0179e8c0$d115c380@ics.uci.edu>
Subject: Re: Version issues



-----Original Message-----
From: Chris Kaler [mailto:ckaler@exchange.microsoft.com]
Sent: Thursday, February 25, 1999 12:27 AM
To: 'jamsden@us.ibm.com'
Cc: gclemm@atria.com; ejw@ics.uci.edu; dgd@cs.bu.edu;
Cragun.Bruce@gw.novell.com; sridhar.iyengar@mv.unisys.com;
bradley_sergeant@intersolv.com; ABabich@filenet.com
Subject: RE: Version issues


<jra>
Today's "level 1" systems probably do have some notion of a workspace,
sometimes called a sandbox, in which individual users do their work. This
is often the local file systems where users checkout or extract the
contents of resources and copy to their local disk. This provides both the
separate contexts to avoid collisions, and efficient updates. However,
WebDAV is about web versioning and should not involve the local file
system.

If there is (at least effectively) a default workspace, then at least an
adminsistrator needs to be able to set its revision selection rule.
</jra>

[CK] There are "level 1" systems that do not have a notion of a workspace
     at.  There are others than use the local file system to separate
     copies.  However, in this case, the server knows nothing.

     WebDAV is about web authoring and versioning web authored content.
     There are examples of the "level 1" systems I am referring to whose
     purpose in life is to generate content for the web.  If they aren't
     the target consumers of WebDAV then I don't know who is.

     My intention here is not to flame or rat hole :-), just to say that
     the can (and do) support basic++ versioning operations on the client.
     I think that forcing these products to implement a level 2 server
     is going to be a burden that they will not take on.  As a result, there
     will be loss of interoperability because the clients will be coded
     against a specific server since they can't rely on level 1 and may have
     to do something different from level 2.


<jra>
This example presents a work flow that I don't think will be effective for
distributed web-based authoring by a broad user community. I think it is
better to detect potential update collisions as early as possible so that
users can proactively plan changes. In the scenarion above, Jill should
fail to checkout foo.htm because Dick already has it checked out. She
should determine what Dick is doing, and if it is in conflict in any way
with what her updates. This is not something she wants to discover after
she's already made a bunch of inappropriate or incomplete changes. This
just makes the merge more difficult and error prone. Jill can decide to do
parallel development, and can create an activity in which to make her
changes. This allows her version of foo.htm to be checked in and made
available to other users even if it isn't merged with Dick's changes. This
supports the common scenario where lines of descent have to split for a
while due to multiple releases.

[CK] I believe your position (a) imposes policy, and (b) assumes that only
     large distributed groups need WebDAV.  We don't need to support every
     scenario, however, I believe that my scenarios are common in existing
     systems, some of which are focused on Web content authoring.  As well,
     we need to address teams of 2 not just high-end scaling.

We could make your scenarios work for level 1, but then they would be
inconsistent with level 2 and present two different versioning semantics.
We need to pick an approach and stick with it.

[CK] I don't believe one rules out the other.  You are assuming a protocol.
     I would like to set the goal and if we can't meet it, then we don't
     support it.  If we don't set the goal, we are likely not to try.

It seems strange to me to consider parallel development and merging as
"very basic versioning". What you described seems more like simple parallel
development that won't scale to the web.
</jra>

[CK] I understand.  I'm not sure how we arrived at two levels.  I'd prefer
     to have 3.  (A) Simple linear versioning, (B) simple paralel
verisoning,
     (C) full configuration management.  We currently have (B) and (C)
lumped
     together and I believe that the cost of (C) will prevent people from
     adopting/supporting level 2.  This means that they have to find there
own
     way for (B) functionality.  It is likely/possible that they can't take
     some of the concepts for (B) from level 2 and just support them.  I say
this,
     because if they could, then we should be able to support it.