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