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

Re: Changes to DeltaV

From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
Date: Mon, 8 Jan 2001 07:04:36 -0500 (EST)
Message-Id: <200101081204.HAA04425@tantalum.atria.com>
To: ietf-dav-versioning@w3.org

   From: "Mark A. Hale" <mark.hale@interwoven.com>

   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.

Yes, the option names (such as "client-workspace" and
"server-workspace") are descriptive terms.  For parallel development
of several resources, you will always need something like a
"workspace", i.e. a place where those resources live with appropriate
relative names.  In the "client-workspace" option, the workspace is on
the client (and therefore have no explicit resource for them on the
server), while in the "server-workspace" option, the workspace is on
the server (and therefore has an explicit resource on the server, the
"workspace resource").

   > > And the bit about a workspace as a precondition: sections 5.5 -
   > > 5.7 actually work without needing "workspaces." It is a bit
   > > confusing because they are placed into the "workspace" section,
   > > when they really just mean "editing resources on the server
   > > [with or without a workspace]." IMO, they should move to a
   > > different section, or somehow be clarified that they do not
   > > require a "workspace" to operate.

   > 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?

I think it is clear my "simplification" is actually confusing things,
so I'll break these would into two separate options as Greg suggests,
namely one option which lets you do CHECKOUT/CHECKIN/UNCHECKOUT of
a version-controlled resource, and another option which lets you create
separate workspaces on the server (the latter is the "server-workspace"

Received on Monday, 8 January 2001 07:05:33 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:46 UTC