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: Fri, 5 Jan 2001 09:25:42 -0500 (EST)
Message-Id: <200101051425.JAA29675@tantalum.atria.com>
To: gstein@lyra.org
CC: ietf-dav-versioning@w3.org
   From: Greg Stein <gstein@lyra.org>

   On Thu, Jan 04, 2001 at 04:07:56PM -0800, Mark A. Hale wrote:
   > Attached are changes from Interwoven for DeltaV (as applicable to
   > draft-ietf-deltav-versioning-10.13.doc).  Please feel free to ask for
   > clarification on any of the items.

   I would suggest that, in the future, you attach these inline as text. Using
   a Word document makes it hard to view them, and practically impossible to
   respond to the points in that document. As a result, I can only call them
   out briefly here.

Yes, 72 column text is the way to go.  I've converted Mark's comments
to text, and will include them inline in this message, preceded by "> >"

   > > 4.7 - Move to strike this section in the current form.  As this
   > > section is stated here, the concept appears to be to create a
   > > privatized workspace resource in which the client is free to apply
   > > version control semantics at will and outside the scope of knowledge
   > > of the server.  This can be accomplished by using GET/CHECKIN/CHECKOUT
   > > semantics without the need for a workspace resource overhead.  In its
   > > current form, any version control applied on the client is not applied
   > > to the resource when it is checked in.  In the future, if these
   > > activities are included with the resource, the workspace resource may
   > > be required.  The workspace resource in this scope has no life span on
   > > the server and may lead to uncontrolled overhead in its current form.
   > > A similar concept that needs to be recognized is the ability for
   > > clients to remain off-line for a long period of time and maintain a
   > > lock on a resource as in the case of off-line editing.  This will need
   > > to be introduced in the future.

   *) The "Client workspace" option is going to stay; there isn't any way to
      get that section tossed. Consider that CVS, one of the most widely used
      version control systems, uses this model.

The key feature of the client workspace option is the ability to have
multiple checkouts of the same version-controlled resource, without
the need to create multiple workspaces on the server.  If you just have
GET/CHECKIN/CHECKOUT, access to a particular version-controlled 
resource is serialized for the duration of the CHECKOUT/CHECKIN, and
intermediate work is exposed.

It would be great to have only one of these models, but after two
years of trying, it's pretty clear that there is no way to unify them,
and both are widely used.

   > > 
   > > 5.0 Need DELWORKSPACE method to delete workspaces no longer in use.
   > > 

   *) DELWORKSPACE is not needed. Just use DELETE

I agree.

   > > 5.0 - Text "(see section 6.2)" should read (see section 7.2)"
   > > 5.0 - Text "(see section 0)" should read (see section 9)"

Will fix.

   > > 
   > > 5.4 - Current form of MKWORKSPACE is for the workspace to be empty on 
   > > initialization.  There should exist three options. 
   > > 
   > > 1. An empty workspace
   > > 
   > > 2. A workspace initialized with the current version of the resources
   > > in a baseline as non-version-controlled resources
   > > 
   > > 3. A workspace initialized with the current version of the resources
   > > in a baseline as version-controlled resources
   > > 

   *) MKWORKSPACE variants:
      -) empty: what we have today


      -) initialized w/ a baseline as non-controlled resources: COPY a baseline
	 selector to the target area instead.

Actually, you'd first BASELINE-CONTROL a collection, with that baseline
and then COPY that collection to the target area.  That target area is
not a "workspace" in any interesting way, so I don't see that you'd
want the destination to be a workspace.  Just any old collection will do.

      -) initialized as controlled resources: MKWORKSPACE followed by
	 BASELINE-CONTROL ought to do the trick. (this is discussed in 5.0)


   > > 5.5-5.7	The workspace must exist as a pre-condition.
   > > 
   > > 5.5-5.7 The version-controlled resource to be operated on by the
   > > CHECKOUT/CHECKIN/UNCHECKOUT methods must have workspace URL.  Note
   > > examples do not reflect this.

   *) your comments on 5.5 - 5.7 don't make sense to me. The URL is the
      version-controlled resource (VCR), and that VCR is in a workspace. There
      is no separate URL for a workspace.

I agree.

      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).

      The "workspace" concept is simply to create other areas on the server
      where a person may work privately or independently.


Received on Friday, 5 January 2001 09:26:36 UTC

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