RE: Comments on Baseline option (in 12.3)

   From: Jim Whitehead [mailto:ejw@cse.ucsc.edu]

   6. Section 10.3.1 & Section 10.11 (DAV:baseline-collection)

   Since this is a protected and computed property,

(actually, I believe it is just a protected, not a computed, property)

   its state is not
   guaranteed to be preserved when a version is made of it, since a
   version is defined to be (Section 1.4) "A 'version' is a resource
   that contains a copy of a particular state (content and dead
   properties)".

A version-controlled configuration does not have a DAV:baseline-collection
property, so I don't see that this issue arises.  It is only a property
of a baseline.

   So, some text is needed to ensure that
   DAV:baseline-collection reverts from being a computed property to a
   dead property, when the version-controlled configuration is
   checked-in.

Since a version-controlled configuration does not have a
DAV:baseline-collection, we happily do not have to do that (:-).

   The text in Section 10.11 seems like it is intended to
   capture this, but since the property is protected and computed,
   stating what the value is at the moment of checkin doesn't provide
   any guarantees of its future value...

Good point.
Tim also pointed out that we're missing some pre-conditions that
make sure that UPDATE, MERGE, and CHECKOUT cannot be used to change
the members of this collection (they are checked-in version-controlled
resources, so no other methods can be used to change them).
I'll add these missing preconditions.


   7. Section 10.10 (additional COPY semantics)

   This looks like a cut-and-paste of the previous paragraph, changing
   only the method.  Is the intent here that this only applies to
   COPYs of collections?

Yes.  I'll add some words like "if the request creates a new
collection at the Destination" to make this clear.

   8. Section 10.6 (definition of BASELINE-CONTROL)

   "If no baseline is specified, a new baseline history is created,
   and the DAV:checked-in version of the version-controlled
   configuration will be the (empty) root baseline of that baseline
   history."

   OK, but what happens if a baseline is specified?  I would guess
   that the version history associated with the version-controlled
   configuration for the baseline specified in the request body would
   be used, right?

Yes.  Since the previous paragraph states:

 "If a baseline is specified in the request body, the DAV:checked-in
 version of the new version-controlled configuration will be that
 baseline"

and since the DAV:version-history is defined to be the
DAV:version-history of the DAV:checked-in version.

   9. GET, PUT OK?

   I'm assuming that, since they're not prohibited, GET and PUT on a
   version-controlled configuration are OK, and wouldn't affect the
   state of the configuration (since that's represented in a
   property).

Yes, we stay deliberately silent about the content of a version-controlled
configuration, an activity, a baseline, a workspace, etc.  We don't have
any interoperable use for it, but we want to leave the door open for
us finding one some day.

Again, thanks for the great review, Jim!

Cheers,
Geoff

Received on Monday, 12 February 2001 11:05:11 UTC