Still need to probe a bit to understand ... your argument against just
representing a snapshot as a new component is that "it would be
artificial". If that set of components is of interest to you, why is it
artificial to give that set a name (i.e. the component)? Note that in
practice in RTC, each of a sequence of snapshots is commonly given some
prefix name, followed by a qualifier. This common "prefix" is
effectively the "component name" for those snapshots. The lack of a
component means that the snapshot naming is manual, since there is no
object to inherit the name from. Note that you cannot effectively
derive the name of the snapshot from the stream or workspace from which
you are creating the snapshot, because successor snapshots can be
created in any stream or workspace, and therefore just using the name of
the stream or workspace does not provide the common prefix desired.

Cheers,
Geoff

David.Sedlock.infineon.com wrote:
gmclemmwrote:
Hi David,
If you had the UCM composite component model you describe below
(deferring the detail on whether one should distinguish components
that
can only contain files from components that can only contain other
components), why would you need snapshots? In other words what
would a
snapshot give you couldn't get just as easily from a composite
component?

As I said in the last paragraph of my posting, if all you want in a
stream or workspace is provided by one composite baseline, the
snapshot is superfluous. If not, not. For example, you have one
composite baseline that gives you part of the components you need and
another composite baseline that gives you another part, but no
composite baseline that gives you all. Then the snapshot provides you
extra functionality.

Why would you want this extra functionality? Well, suppose you have
some components that are the sources for your application and some
components that are optional add-ons. There is no desire to release
them together and hence no need to have a composite baseline for
both, but it is still convenient to be able to reproduce a workspace
configuration that includes both. It would be artificial to create a
component that contains them. The snapshot is the better way here,
and is an improvement over UCM. So I don't recommend getting rid of
the snapshot - or extending it to do duty for composite baselines.

gmclemmwrote:
Hi David,
If you had the UCM composite component model you describe below
(deferring the detail on whether one should distinguish components
that
can only contain files from components that can only contain other
components), why would you need snapshots? In other words what
would a
snapshot give you couldn't get just as easily from a composite
component?

As I said in the last paragraph of my posting, if all you want in a
stream or workspace is provided by one composite baseline, the
snapshot is superfluous. If not, not. For example, you have one
composite baseline that gives you part of the components you need and
another composite baseline that gives you another part, but no
composite baseline that gives you all. Then the snapshot provides you
extra functionality.

Why would you want this extra functionality? Well, suppose you have
some components that are the sources for your application and some
components that are optional add-ons. There is no desire to release
them together and hence no need to have a composite baseline for
both, but it is still convenient to be able to reproduce a workspace
configuration that includes both. It would be artificial to create a
component that contains them. The snapshot is the better way here,
and is an improvement over UCM. So I don't recommend getting rid of
the snapshot - or extending it to do duty for composite baselines.

I have thought hard about whether we could live without composite
baselines and come to the conclusion that it would make life
unnecessarily difficult. The snapshot is helpful, but not good
enough. Here is a sketch of how composite baselines could be
introduced cleanly into RTC.

1) The concept of a component is extended to make it recursive - that
is, a component can contain either a set of files or a set of
components. We call a component that contains other components a
"composite component". Note that the "or" here is
exclusive: UCM made a mistake when it allowed components to contain
both baselines and files.

2) The components a composite component contains depends on the stream
or workspace in which it appears. In different streams and workspaces
it can contain different components.

3) A component baseline is either a set of file-versions or a set a
baselines. The "or" is again exclusive.

4) In the workspace and stream, the representation of a flat list of
baselines is extended to a list of trees.

5) The trees can be manipulated in the workspace to represent a
different structure. For example, suppose we start with a flat list
of baselines:

comp1_initial
comp2_bl1
comp3_bl1

We then decide we want to package comp2 and comp3 together, so we
change the tree to place them under comp1. This triggers the creation
of a new baseline in comp1, with the following result:

comp1_bl1 
	comp2_bl1 
	comp3_bl1 

6) The new baseline appears at an outgoing change. Delivering it
changes the baseline structure in the stream. Accepting it into other
workspaces brings them into sync with the new structure.

7) From now on in these workspaces, when a new baseline is created in
comp1, new baselines are also created in comp2 and comp3, if needed,
and included in the new baseline in comp1.

8) When a baseline of a composite component is replaced in a stream or
workspace, its structure comes with it.

9) If a component appears more than once in a stream or workspace
(i.e. in different trees), with different baselines one of the
baselines is chosen by default. The user can change this. Such
"baseline overrides" are clearly marked.

Note that composite baselines do not replace, but rather complement
snapshots. In the limiting case when there is only one tree in a
workspace, the snapshot is no longer needed since the composite
baseline of that component provides the functionality of a snapshot,
but in all other cases, the shapshot provides more.