RE: Changes to DeltaV

Just to work with you some more on our suggestions:

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

I do not think that we are far apart here.  I see two issues:

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

>    > >
>    > > 5.0 Need DELWORKSPACE method to delete workspaces no longer in use.
>    > >
>
>    *) DELWORKSPACE is not needed. Just use DELETE
>
> I agree.

OK

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

Thanks!

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

I agree that the two-phase approaches will work.  IMHO, I envisioned a
single-phase scenarios where a user would like to take a baseline into a new
workspace and have it fail if not possible.

This is a nice to have but not needed.

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

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?

	Thanks again for taking the time,

	Mark

Received on Monday, 8 January 2001 00:24:56 UTC