- From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
- Date: Fri, 5 Jan 2001 09:25:42 -0500 (EST)
- 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 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. > > 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. Yes. Cheers, Geoff
Received on Friday, 5 January 2001 09:26:36 UTC