RE: Baselines and Bindings

   From: Alison Macmillan [mailto:alison.macmillan@oracle.com]

   ... the DAV:set-baseline-controlled-collection-members
   postcondition added by BASELINE to UPDATE (and MERGE), should
   include a statement similar to that in
   DAV:update-version-controlled-collection-members, requiring the
   creation of a binding to an existing VCR in the workspace.  Is this
   the right interpretation?

Yes.

   Is it also right to imply that the DAV:checked-in version of the VCR
   (assuming that it is checked-in) remains as it was preceding the MERGE /
   UPDATE, in particular the DAV:checked-in version does _not_ necessarily
   match the version held in the baseline?

No, the DAV:checked-in version will be updated.
For an UPDATE, the version should be set to be the version held in the
baseline.  For MERGE, it should be the MERGE of the version held in
the baseline with the version held in the workspace (i.e. whichever
one is the descendent of the other, otherwise checked out with the
merge version added to the DAV:merge-set).

   Should there be a similar extension to the DAV:select-existing-baseline
   postcondition? This would cover the case of initializing a collection
   from an existing baseline, where the collection is a member of a
   workspace, and both the workspace and baseline contain VCRs for the same
   version history.

Yes (this would set the existing VCR to be the version specified in
the baseline).

   Also, how should BASELINE-CONTROL behave on a workspace containing such
   duplicate bindings? For example, suppose a workspace contains
   /ws/cmp1/src/foo.html and /ws/cmp2/src/bar.html, and that
   /ws/cmp2/src/bar.html is a binding (another name for) the resource,
   /ws/cmp1/src/foo.html.  If you  first
   BASELINE-CONTROL /ws/cmp1, and then BASELINE-CONTROL /ws/cmp2, should
   the second BASELINE-CONTROL operation  omit the VCR identified by
   /ws/cmp2/src/bar.html (because it is already a member of a configuration
   created by baseline-controlling  /ws/cmp1)? If it is omitted, then it
   seems like the baseline of cmp2 has lost some important information
   about the structure of component 2 (cmp2). If it is not omitted, then it
   seems to conflict with the description of configuration membership.

Yes, in this case, the baseline of cmp2 would not contain a version
of /ws/cmp2/src/bar.html (that would have to be provided by a baseline
of cmp1).  If you have versioned collections, the version of 
/ws/cmp2/src would indicate that it has a member (named bar.html), and
would know its version history, but the version would need to be
specified by a baseline of cmp1.  If you made a baseline of cmp1 a
sub-baseline of the baseline of cmp2, this would ensure that a version
would be selected any time that baseline of cmp2 was selected.

Cheers,
Geoff

Received on Wednesday, 10 October 2001 23:59:35 UTC