RE: BASELINE-CONTROL

   From: Konstantin Knizhnik [mailto:KKnizhnik@togetherlab.com]

   Assume that I have some project /project1
   (version-controlled-collection) placed under baseline control. I
   have some baseline with subbaselines. Subbaseline refer to some
   components in the project - some collections which are members of
   the /project1 collection.  Now I want to place project in my
   workspace. I create directory /ws/my/project1 and place it under
   version control, right?

Actually, you create directory /ws/my/project1 by using the 
BASELINE-CONTROL method, specifying the baseline from /project1
that you want to initialize /ws/my/project1 with.

   But what how subbaselines will be handled? The expected behavior is
   that subbaselines will be extracted to the correspondent
   subdirectories of /ws/my/project1 which will be placed under
   baseline control? But I didn't find confirmation in the
   specification.

See the recent thread on "baselines & namespaces" (starting last
week).

   Also specification doesn't require that baseline-controlled-collection of
   the subbaseline is member of baseline-controlled-collection of the
   super-baseline.

That is correct.

   In this case I will not be able to create collections
   for subbaselines when I place /ws/my/project under baseline control.

If the subbaselines are not under /ws/my/project1, they must be
independent projects, e.g. project2 and project3.  You would therefore
have to initialize your workspace with those other projects as
well, by using additional BASELINE-CONTROL requests (i.e. creating
/ws/my/project2 and /ws/my/project3).  It obviously is easier if
all the sub-projects are nested under a common "namespace", because
then a single BASELINE-CONTROL request is sufficient.

   So while behavior explained in the previous section seems to be
   natural and obvious, I afraid that it is not what intended for
   subbaselines by specification. Unfortunately there is almost
   nothing in specification about subbaselines, except brief
   explanation of subbaseline property.

We need to add this kind of info to the FAQ.  Hopefully this thread
provides the material we will need for this.

   Now when I am going to prepare new baseline, I will have to
   explicitly setup subbaselines property for this baseline.  Why the is
   no notion of "subconfiguration". It seems to very convenient and
   natural: I have version-controlled-collection /project1, I have
   component /project1/gui, project1/db and project1/core.
   I place them under baseline control and declare that configuration of
   /project1 has three subconfigurations. Now when I checkin this
   configuration and produce new baseline for /project1, this baseline
   will automatically be assigned subbaseline property, referred to the
   checkedIn baselines selected by subconfigurations. Does it make sense?

Yes, I think that is exactly right.  Until now, there were only a few
folks interested in advanced baselining functionality, so we just
ended up defined the basic machinery and left the elaboration for a
future draft (there are some interesting issues that arise when that
kind of machinery is defined).  But now that we have several folks
interested in sub-baselining, we should go ahead and iterate on some
semantics, and get it posted to the deltav web site.

   And one more question about baselines: it is said in specification that
   "the root collection of a configuration is unconstrained with respect
   to its relationship to the root collection of its components".
   First of all,  the notion "root collection of configuration", been
   introduced in the first abstract of section 12 (Baseline
   feature), is never more used. So it is not clear what is it and how it
   can be used.

The concept of a "root collection" appears is explicitly used in a
variety of the method postconditions in the baseline feature (just
search for the string "root" in the protocol text).

   BASELINE-CONTROL method creates new configuration 

to be precise, it creates a new version-controlled configuration.

   and either create
   new baseline bounded with specified version-controlled collection
   either initialize specified version-control-collection with existed
   baseline.

It does not need to be a version-controlled collection ... whether
or not a collection is under version-control or baseline-control
are two orthogonal issues (it can be neither, either, or both).

   This version-controlled-collection is stored in
   <DAV:baseline-controlled-collection/> of the configuration.

More precisely, the location of the baseline-controlled collection
is stored in the DAV:baseline-controlled-collection property
of the version-controlled configuration.

   It is "root collection of configuration"?

More precisely, it is the root collection of the configuration whose
state is being tracked by the version-controlled configuration.

   If so, how it is possible that components of this collection are
   not members of this collections?

A version-controlled configuration is not itself a configuration (it's
not even a collection), but rather is a mechanism for tracking the
history of a configuration (in particular, the configuration whose
root is identified by the DAV:baseline-controlled-collection property
of the version-controlled configuration).

Cheers,
Geoff

Received on Tuesday, 18 December 2001 08:42:28 UTC