W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > January to March 2001

Re: Changes to DeltaV

From: Greg Stein <gstein@lyra.org>
Date: Mon, 8 Jan 2001 13:44:58 -0800
To: ietf-dav-versioning@w3.org
Message-ID: <20010108134458.H4141@lyra.org>
On Sun, Jan 07, 2001 at 09:27:47PM -0800, Mark A. Hale wrote:
>...
> a) The ability to have multiple checkouts of the same version-controlled
> resource accomplished through the creation of a working resource
> b) An area where one or more non-version-controlled or version-controlled
> resources can exist for segregated use by the user
> 
> I believe that b) is what a workspace is.  The concept of 'client' and
> 'server' workspace do not make sense to me unless you are trying to use it
> to mean a descriptive term to describe where version control is being done.
> What is referred to as 'server-workspace' in the draft is a workspace that
> exists on the server that is client accessible.
> 
> I trust your implementation experience with a).  Your description helped and
> is immediately evident when one reads section 4.  However, I do not feel
> that a working resource is a workspace and, logically, the working resource
> should be accessed in the context of a workspace.

The workspace exists on the client computer. The working resource is just a
transitory resource to get the changes merged from the client onto the
server.

The working resources exist "somewhere" on the server. They don't
necessarily have any organization or known location. (heck, they could even
be on a different server from the main repository!)

> Can we keep the concept
> of a working resource but move it to exist inside of a workspace, with the
> understanding that a workspace is addition overhead but helps in the logical
> separation?

There isn't a need to organize the working resources. They come and go
simply as a way to get the changes onto the server.

>...
> > Yeah, that was just a somewhat forced attempt to cut down on the
> > number of options.  It seemed like the only people asking for
> > "in place checkout" were those who were planning on implementing
> > workspaces, so I bundled "in place checkout/checkin" with the
> > workspace option.   Another way to look at it is that a server can
> > support the "server-workspace" option, but fail a user's attempt
> > to create new workspaces with MKWORKSPACE.  I'd probably prefer
> > this over splitting this into two separate options (although I agree
> > that they are logically separable).
> 
> I need to think about this one some more.  If the version-controlled
> resource (VCR) is in a workspace, doesn't the workspace need to exist as a
> precondition regardless of whether or not a separate URL for the workspace
> can be discriminated?

You can work with a VCR independent of the notion of a DeltaV workspace.

If you have a workspace, then if VCRs are in that workspace, then the
"existence precondition" is obviously met :-)

But note that you can have VCRs that are *not* in a DeltaV workspace.

A URL layout might be:

    /ws
    /ws/vcr1
    /ws/vcr2
    /ws/vcr3/vcr4
    /ws/vcr3/vcr5
    /vcr6
    /vcr7

/ws is the workspace and VCRs 1 thru 5 are in it. VCRs 6 and 7 are not in a
workspace.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
Received on Monday, 8 January 2001 16:45:23 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:39 GMT