RE: Baselines and Bindings

Hi,

I understand why the baseline of cmp2 would not contain a
version of /ws/cmp2/src/bar.html, but this does seem odd.

I can think of a common use case for which this may cause problems:

Imagine you have a workspace:

/ws/project1

This is web site and various pages on the site use a common JAVA Script 
based advert banner.  So in your workspace you have:

/ws/project1/adverts.js        (this is a VCR)
/ws/project1/default.htm       (this is a VCR)
/ws/project1/news              (this is a collection)
/ws/project1/news/adverts.js   (rather than another copy of advert.js this
is just a binding to
                                the VCR at /ws/project1/adverts.js).
/ws/project1/news/default.htm  (this is a VCR).

So you have the adverts.js file used at both the top level of the web site
and in the news section of the website.

Now lets imagine you do a BASELINE-CONTROL on /ws/project1/news to capture
the news section
of the site in a baseline.  The baseline collection will have a member which
is a binding to
/ws/project1/adverts.js (since the baseline-controlled collection had a
binding to this VCR).

Now imagine you do a BASELINE-CONTROL on /ws/project1 according to Geoffs
e-mail I think
this will NOT contain adverts.js, it will only capture the default.htm,
because the VCR
for adverts.js already has a DAV:version-controlled-configuration property
and so cannot
be a member of two configurations.


This seems really odd, because now if you use BASELINE-CONTROL to populate a
new collection
with the contents of the baseline that you took of /ws/project1 it will NOT
create a advert.js
at the top level and so the web page would be broken!  Even if the baseline
of /ws/project1/news
was a subbaseline of the baseline of /ws/project1, the adverts.js would
still NOT be created
at the top level when the /ws/project1 baseline is used.

I don't have a good answer to how I would propose we fix this, but it
certainly seems like
a problem.  We could always just capture one baseline of /ws/project1 and
NOT capture
/ws/project1/news as a baseline (eg just have one baseline of the whole
thing), but this
is forcing the user down this route, they may have wanted to track
/ws/project1/news
as a component.

Am I on track?

Regards,
--
Peter Raymond - MERANT
Principal Architect (PVCS)
Tel: +44 (0)1727 813362
Fax: +44 (0)1727 869804
mailto:Peter.Raymond@merant.com
WWW: http://www.merant.com



-----Original Message-----
From: Clemm, Geoff [mailto:gclemm@rational.com]
Sent: 11 October 2001 04:59
To: ietf-dav-versioning@w3.org
Subject: 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