Re: Version issues

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

From: Jim Whitehead <ejw@ics.uci.edu>
To: Versioning <ietf-dav-versioning@w3.org>
Date: Thu, 1 Apr 1999 16:58:14 -0800
Message-ID: <003701be7ca3$e3202240$d115c380@ics.uci.edu>
Subject: Re: Version issues



-----Original Message-----
From: Chris Kaler [mailto:ckaler@microsoft.com]
Sent: Saturday, February 20, 1999 11:27 PM
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


Edited down...

<jra>
I don't see workspaces adding complexity, in fact I seem them removing it.
Again, what needs do existing "level 1" clients have that workspaces don't
fit? Please quantify the complexity with concrete examples. I think I have
given a number of examples where workspaces in level 1 do have preceived
value.
</jra>
[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>
We said level 1 clients don't have parallel development. That's level 2.
Again, just allowing branches doesn't support parallel development. You
have to be able to do something with those branches after you create them.
[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.

How is updating an RSR complex? Workspace could have methods to add and
remove entries to/from the RSR. The current model just uses an XML document
fragment, just like PROPFIND and PROPPATCH, but we could add some
convenience methods to the model and/or protocol. Updating an RSR will
usually be just adding or removing a label and/or configuration (for level
2). Why do you think this is complex?
</jra>
[CK] As I said in my previous mail, I was assuming that you had to do a
        PROPFIND and then a PROPPATCH.  I realized you weren't saying
        That...

<jra>
I'm still looking for that use case from you describing this requirement.
</jra>
[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.


Chris