Re: Version issues
Jim Whitehead (ejw@ics.uci.edu)
Thu, 1 Apr 1999 16:58:34 -0800
From: Jim Whitehead <ejw@ics.uci.edu>
To: Versioning <ietf-dav-versioning@w3.org>
Date: Thu, 1 Apr 1999 16:58:34 -0800
Message-ID: <003801be7ca3$ef1b2680$d115c380@ics.uci.edu>
Subject: Re: Version issues
-----Original Message-----
From: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com]
Sent: Wednesday, February 24, 1999 7:53 AM
To: Chris Kaler
Cc: 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
See jra tags below...
Chris Kaler <ckaler@microsoft.com> on 02/21/99 02:27:14 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
Edited down...
[CK] For today's "level 1" systems, there is no notion of workspace.
I agree that such a concept would be an interesting addition,
but forcing it would mean an additional concept that the users
of the system don't need. However, I think the idea that there
is, conceptually, a default workspace is fine - so long as neither
the client or the protocol care about it in level 1.
<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] I don't think we ever agreed on that because I know I would
have objected :-). In today's basic systems, you can check out
the same document twice, or, multiple versions simultaneously.
We have to support this behavior without requiring clients and
servers to move to level 2. This is where I think we have the
biggest problems.
[CK] Here are two... there are more... Dick is working on the latest
version
of the HR Manual. He has it checked out using his level 1 client
against their level 1 server. Jane found a typo in the previous
verison
of the HR manual and needs to check it out to fix it. This means
the
default workspace must support checkouts of different versions of
the same file. Jack and Jill work on a system that uses very basic
versioning, but their client does understand merging. Jack checks
out foo.htm to fix a bug in his script code. Jill is working on a
problem
with a server applet and finds a bug in foo.htm. She also checks
it
out. When Jill goes to check in, she finds that Jack has already
checked in and she must merge her change. This requires the
default
workspace to support multiple checkouts of the same resource.
I do not believe we can require a level 2 client and server to
support
these basic scenarios. Unless you want to say Level 1 is basic
versioning, level 2 is basic + parallel, and level 3 is
sophisticated SCM.
<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.
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.
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>
Chris