RE: Re (4): Re[2]: baselines & namespaces

   From: Edgar@EdgarSchwarz.de [mailto:Edgar@EdgarSchwarz.de]

   "Clemm, Geoff" <gclemm@rational.com> wrote:
   >    > If your server supports baselines and versioned collectios, then
   >    > it MUST create /ws/kk/x/y when /repo/bl/22 is merged into /ws/kk.
   > 
   >    Why should this be required ? /ws/kk/x/y wasn't captured in the
   >    baseline, so there is no information how to restore it.
   > 
   > The baseline /repo/bl/22 contains a collection version for "./x/y",
   > and this collection version has a version-controlled binding named
   > "y".

Note: I meant to say "the baseline /repo/bl/22 contains a collection
version for ./x".  Sorry about the typo.

   That's already the point I don't understand.
   My reasoning goes like that:

   0. It doesn't matter whether the server also has versioned
      collections because baselines and versioned collections are
      independent features.

Depends how you define "matters".

   1. /repo/bl/22 is a baseline of the configuration rooted at "./x".

Yes.

   2. It was explicitly stated in the original question that "./x/y"
      is the root of another configuration which isn't a subbaseline
      of "./x".

Yes.

   3. A baseline is a set of versions of version-controlled-resources
      with the exception of resources which belong to another
      configuration.

   => Baseline /repo/bl/22 doesn't contain a collection version for "./x/y",
   So where's my error ?

That was my typo.  It contains a collection version for "./x", not
for "./x/y".  BUT, the collection version for "./x" contains a
version-controlled binding named "y", and that is what forces the
creation of a VCR named "/ws/kk/x/y" (although it does not specify
what version of /ws/kk/x/y is to be selected).

   > This is allowed to provide consistent semantics in the presence of
   > versioned collections.  A version of a collection captures a set of
   > version-controlled bindings, and an appropriately named binding to a
   > VCR must exist when that collection version is restored
   > (i.e. specified in the DAV:checked-in property of a version-controlled
   > collection).

   After thinking about my points above I guess that you probably
   already disagree with point 0. Right ?

Well, it depends how you define "matters".  One clear way in which
they interact, is that if your server supports version-controlled
collections, then a baseline will contain versions of collections,
while if it doesn't, a baseline will not.  And it is the version of
a collection which introduces the behavior we are discussing.

   In this case I think I can stop argueing with you. Because as long
   as there aren't versioned collections I think we agree.

Yes, if a server does not support version-controlled collections, then
it can chose to not create a VCR named /ws/kk/x/y.  But note that a
client must be prepared for /ws/kk/x/y being created, since that is
what it will see on a server that supports version-controlled
collections.

   Now suppose there are only baselines. In an earlier post you
   granted that it would make sense for the server to save the
   relative position of the subbaseline somehow.  So it knows where to
   restore it later.

I agree that for "immediately nested" sub-components, it makes sense,
but for non-nested sub-components, it probably does not.
Suppose you have a baseline for /ws/gmc/xx that has a subbaseline
named /ws/gmc/yy.  And you have a baseline for /ws/es/zz that has
a subbaseline named /ws/es/yy.  Then you "merge" the baseline for
/ws/es/zz into /ws/gmc.  You get a name collision for /ws/gmc/yy.

   Do we already have a property to do that ? If not I think we should
   create it.  Or is there another mechanism using existing features ?
   At least is should be guaranteed that subbaselines are restored to
   the same relative position like when the baseline was created.

The purpose of a baseline is to allow you to MERGE (or UPDATE) that
baseline into a workspace.  You don't need a property to achieve
those semantics, but just have to specify the semantics that are
required following the MERGE (or UPDATE).  The main reason we didn't
specify this as an independent postcondition is that in the
defined packages, version-controlled collections always appear
whenever baselines appear, so this postcondition follows from the
existing postconditions of those two packages.

I expect that adding the postcondition that nested subbaselines are
restored in their same relative location will be acceptable to
everyone, so the best approach here is probably to get this written up
and posted to the deltav web site, so that deltav implementors are
aware of it as a likely addition in the next rev of the deltav spec.

Cheers,
Geoff

Received on Friday, 28 December 2001 10:22:35 UTC