Re: Version issues

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

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



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





---------------------- Forwarded by Jim Amsden/Raleigh/IBM on 02/25/99
10:31 AM ---------------------------


Jim Amsden
02/25/99 10:30 AM

To:   Chris Kaler <ckaler@Exchange.Microsoft.com>
cc:
Subject:  RE: Version issues  (Document link not converted)

Chris,

Good set of comments. See <jra2> reply below.




Chris Kaler <ckaler@Exchange.Microsoft.com> on 02/25/99 03:26:41 AM

To:   Jim Amsden/Raleigh/IBM
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.
<jra2>
I'm not suggesting these servers have to support level 2, only if we define
some down-level functionality that it be a consistent subset of level 2. It
should not introduce alternative, redundant, or inconsistent mechanisms for
functions already supported in level 2.
</jra2>

<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.
<jra2>
Yes, I suppose it is a policy, but so is your scenario. I don't think
there's anything about this policy that can't be supported by existing
systems, even if it doesn't take advantage of some flexibility they may
offer. WebDAV does need to support large distributed workgroups, that's the
Web. Any simplifications have to be consistent with this larger goal.
</jra2>

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.

<jra2>
Sure. But I'm still stuck on how a server will distinguish multiple working
resources checked out from the same revision.
</jra2>

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.
<jra2>
I agree. I don't know why there are only two levels either. We originally
talked about making parallel development and configurations optional. That
still sounds reasonable to me. Maybe we could come up with some minimal
support for parallel development in level 1 that didn't include activities
or merging, even if its just some usage patterns on other functionality.
</jra2>