(You can have a workspace picks up different components from
different streams, but that involves more effort in setting up and
managing those workspaces, so you wouldn't want to do that unless
there >is some good reason for doing so).

Comments below:

David Ward wrote:
Yet another SCM question about how to arrange components and streams.

My project has about 6 components, each of which I regard as
separately buildable pieces of software. Is there any other working
definition of a component ?

Pragmatically, a component is a set of files/directories that are
baselined together. Also note that "moving" a file/directory works most
smoothly within a component, so that motivates you not to make
components too small.

To me, separately buildable implies that each has its own unique
change history. Does this mean that each component should be in its
own stream ?

Whether or not something is a component is independent of whether or not
it appears in more than one stream. In general, you add a component to a
stream whenever you want files of that component to appear in that
stream. (You can have a workspace picks up different components from
different streams, but that involves more effort in setting up and
managing those workspaces, so you wouldn't want to do that unless there
is some good reason for doing so).

My developers usually only need a subset of the components since only
some of them are being actively worked on. Is this another reason to
put components in their own stream or is RTC comfortable allowing
developers to load only some components ?

RTC makes it very easy for developers to declare what components they
want in their repository workspace, and then to declare what files from
the repository workspace should be loaded into their file system sandbox.

I know RTC can go either way but I'd like to understand what the Jazz
project itself does in this regard, and what the design intent of the
RTC SCM is.

We follow the practices described above (:-).

Cheers,
Geoff