Re: CHECKIN and properties

   From: "Jim Whitehead" <ejw@cse.ucsc.edu>
   Date: Wed, 31 Jan 2001 17:42:14 -0800

   Section 2.2 and Section 2.3:

   Is it a MUST level requirement that a core versioning server support all of
   the properties in sections 2.2 and 2.3?  I.e., MUST a version-controlled
   resource have all of the Section 2.2 properties defined upon it (well,
   really, all that are appropriate for its checked out/checked in state), and
   MUST a version resource have all of the Section 2.3 properties defined on
   it?  If so, I couldn't find a place that explicitly states this.

I'll add the statement that the properties defined by core or an option
are REQUIRED for core or that option.

   Section 2.2.3:

   It seems like, most of the time, the server will be setting the value of
   DAV:predecessor-set, and except for merges, or adding to the server-computed
   value, the client shouldn't try to write to this property.  Is this correct?
   If so, it would be nice to capture this in Section 2.2.3, so client writers
   have a better expectation about how this property works.

There are common cases when branching is disallowed but multiple
checkouts are allowed where a client will be updating the predecessor
set.  I believe this is better handled in the scenarios document or
FAQ, and not in the protocol document itself.

   Section 2.2.5:

   This seems underspecified to me. There are really two parameters here,
   resource is write-locked/unlocked, and autoversion status of when-unlocked,
   and when-locked.  ...

I'll fix this.

In particular, there are really only 3 interesting combinations:

DAV:always-checkout-always-checkin
DAV:always-checkout-when-unlocked-checkin
DAV:when-locked-checkout

   Also, what happens when the resource is write-locked, and the value of
   DAV:auto-version is changed from when-locked to when-unlocked?  Is a version
   automatically created upon successful completion of the PROPPATCH (because
   there would already be an active CHECKOUT due to the lock, and the
   when-locked condition)?

Yes, the postcondition of UNLOCK does not depend on the current state
of the DAV:auto-version property.

   Section 3.2:

   CHECKIN takes a version-controlled resource, and turns it into a version
   resource which is a copy of its body and dead properties.  Properties that
   must exist on a checked-out version-controlled resource are:

   DAV:checked-out
   DAV:predecessor-set
   DAV:precursor-set
   DAV:auto-version

   Which of these properties should be transferred over to the version resource
   created by CHECKIN?  My guess is:

   DAV:checked-out: no
Yes, properties that are not explicitly stated as being transferred are
not transferred.
   DAV:predecessor-set: yes
   DAV:precursor-set: yes
Oops!  Forgot this one ... will fix.
   DAV:auto-version: no

   At the very least, this issue is not currently addressed in the
   specification (except for DAV:predecessor-set).  DAV:precursor-set behavior
   is described implicitly (by the existence of the property on a version
   resource) -- I think it should be made more explicit, in the description of
   CHECKIN.

It is, in the DAV:initialize-version-content-and-properties postcondition.

   The text describing the (DAV:checked-in) postcondition should explicitly
   note that the properties being discussed are on the version-controlled
   resource, and not the version resource.

Will do.

Cheers,
Geoff

Received on Monday, 5 February 2001 01:15:22 UTC