RE: Version Controlled Collection , PostConditions

   From: Vikram_Roopchand [mailto:Vikram_Roopchand@infosys.com]

   The Postconditions in case of Version Controlled Collection

   "14.11 Additional UPDATE and MERGE Semantics

      Additional Postconditions:

	 (DAV:update-version-controlled-collection-members): If the request
	 modified the DAV:checked-in version of a version-controlled
	 collection, then the version-controlled members of that version-
	 controlled collection MUST have been updated.  In particular:
         - ...
	 -  A new version-controlled internal member MUST have been created
	    when a version history is identified by the DAV:version-
	    controlled-binding-set of the DAV:checked-in version, but there
	    was no member of the version-controlled collection for that
	    version history.  If a new version-controlled member is in a
	    workspace that already has a version-controlled resource for
	    that version history, then the new version-controlled member
	    MUST be just a binding (i.e., another name for) that existing
	    version-controlled resource.  Otherwise, the content and dead
	    properties of the new version-controlled member MUST have been
	    initialized to be those of the version specified for that
	    version history by the request.  If no version is specified for
	    that version history by the request, the version selected is
	    server defined."

   In the last point, it is written "...then the new
   version-controlled member MUST be just a binding".
   I am unclear about this "binding" , since the term
   "version-controlled member" has been used alongwith it,

The term "binding" is defined in Section 10.2 as part of the
"Collection" definition.

   does it mean that another VCR having DAV:checked-in the same as
   that of already existing VCR should be created (which violates
   workspace semantics ?) or will there be a non versioned member
   created (having the content and dead properties of the already
   existing VCR )?

Neither.  It is like a Unix hard link, i.e. two names in two different
collections identify exactly the same resource.  

   If it is the first case , then how will checkouts/checkins/merge be
   handled on both VCR's ?

If you make a change to the resource at one of its names, that change
is visible at its other name (since both names identify the same
resource).  Two names ... one resource.

Cheers,
Geoff

Received on Thursday, 6 February 2003 16:13:35 UTC