RE: Versioning Goals feedback

Here's more feedback...
[Note that I reference Bruce's comments and Jim's replies]
- Jim: Excellent work pulling this together - Thanks!
- It would be great if the scenarios were numbered
- In "Creating a Versioned Resource": we talked about not using
 CHECKIN as the way this occurs. I would like to re-iterate that
 I think we should have a separate method.
- I'm worried that the scenarios and goals assume that there are
 workspaces and activities. We have had some mail exchanges on
 the subject and I thought I would mention here that I don't
 believe either should be visible to a Level 1 client.
- I think we need a scenario for getting a specific revision. Joe
 lists the history and decides that the revision whose revision id
 is 32345 is the desired version. Joe's client directly obtains
 this revision from the server.
- The "Parallel Development with Activities" section leaves one with
 the impression that you can only do parallel checkouts via activities.
 I believe that Level 1 must support parallel checkouts and shouldn't
 require activities.
- The last paragraph of "Parallel Development with Activities" confused
 me. If one person wants to prevent checkouts, they would lock the
 versioned resource not the working resource. ??
- I believe that the merge stuff is interesting but more complex than
 we need to address in the first draft of versioning. I think that
 we will find it difficult to agree on how you express the differences,
 the rules, communication, etc. I would rather address this stuff in 
 a subsequent draft/effort after we get some of the simple concepts
handled.
- Same comment for the last paragraph of "Creating a Configuration" -- this
 walks into the merge path.
- I don't understand how the "Changing a Revision" section is different
 from "Editing a Mutable Revision". Aren't they saying essentially
 the same thing? Or did I just miss it? :-)
- The "Accessing Resources by Non-Versioning Aware Clients" assumes there
 is always a workspace notion. If we are describing this as a model, OK,
 but if the client or server have to know about this for Level 1, I think
 this is an issue. See previous mail.
- Several times the revision "label" is used. I think people will often
 want to use the revision "id".
- The last paragraph of "Updating Resources by Non-versioning Aware Clients"
 goes into a discussion of workspaces and activities. I assume that a
 down-level client knows neither.
- Can we add a scenario about configurations related to other configuration?
 Alice is using the Beta1 configuration and finds a bug. She fixes the
 bug and checks it in. She creates a new configuration, Beta1a which
 consists of the "Beta1" configuration plus the changes in the "Bug1223"
 activity.
- Goal 1: I agree with Bruce that a down-level PUT could result in the
 server automatically branching.
- Goal 5: I believe this is needed. We see several usage scenarios where
 different revisions are checked out simultaneously.
- Goal 15: In response to Jim's update to this goal -- I believe that
 both live and dead properties can be mutable (or immutable).
- Goal 17: I agree with Bruce that you should be able to delete a
 revision without deleting its successors. However, I'm fine with
 saying that a server MAY refuse the request.
- I think we need a Goal 22.5 that states that simple parallel development
 must be possible without activities.
- Goal 23.1, bullet 2: I should be able to use a revision id as well
- Goal 23.1, bullet 3: I should be able to checkout and create a
 working resource without using activities.
- Goal 23.2, bullet 3: I think this should be "revision labels" since
 there can only be a single revision id and this section is all about
 labels.
- Goal 23.3, bullet 3: I don't think we should be addressing merge at
 this point. We should constrain the problem so that we can generate
 a protocol. We can then layer merge semantics on top in a separate draft.
- Goal 23.4, bullet 3: I should be able to access a revision using
 the URL of the versioned resource and a configuration name since
 a configuration uniquely selects a single revision.
- Goal 23.4, bullet 5: I would like to add into this that is must be
 possible for a client to determine this. My point is that the protocol
 doesn't need to support this exact operation if a client, using other
 mechanisms, can determine this information.
- Goal 31: This should be true inside or outside of an activity.
Thanks for all the hard work Jim, this is starting to come together.
Chris

Received on Thursday, 18 February 1999 20:07:40 UTC

AltStyle によって変換されたページ (->オリジナル) /