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