A request to simplify this appears in workitem 90157: It should be much
simpler to declare "the following components are read only in this stream"

Please feel free to add your comments/support to this work item.

Cheers,
Geoff

Brian Gillan wrote:

Geoff, I don't completely follow your discussion regarding restricting a
stream... I was pointed to this article
http://jazz.net/library/article/215#componentadvisor, but it seems like
a very convoluted way to achieve what we want... to simply make access
to a component read-only in a given stream. Seems like ClearCase had
this capability with UCM projects, where when creating a project or
stream (can't remember which) you could select that components could be
modifiable or not.

Regards, Brian

Geoff, I don't completely follow your discussion regarding restricting a
stream... I was pointed to this article
http://jazz.net/library/article/215#componentadvisor, but it seems like
a very convoluted way to achieve what we want... to simply make access
to a component read-only in a given stream. Seems like ClearCase had
this capability with UCM projects, where when creating a project or
stream (can't remember which) you could select that components could be
modifiable or not.

Regards, Brian

Somebody has to actually do the update in the product stream, so that
person has to have permission to update that component in the product
stream (RTC SCM does not allow the configuration of a component in one
stream to be modified as a "side effect" of modifying the configuration
of a component in another stream, because that would either:
- overly constrain how that component can be modified in the other
stream, or
- bypass the modification rules of the one stream

But I agree that you should be able to declare that "only the component
configuration of this stream can be used to update the configuration of
that component in this other stream". Unfortunately, you cannot declare
that today, but this a work item (86817: "Restricting a stream so that
it can be updated only with the configuration of one of its child
streams") requesting this functionality. As always, please feel free to
add comments/support to that workitem.

Cheers,
Geoff

Brian Gillan wrote:

Geoffrey Clemm wrote:
Yes, add the common component to all the streams/workspaces that need it.

WRT how to control what configurations of that common component are
used by different streams, I suggest creating a separate
"common-component-stream" for each logical line of development of that
common component.

Then each product stream would have a "promotion" workspace, which has
both the product stream and the "appropriate" common-component-stream
as its flow targets. Someone would then periodically go into the
promotion workspace, accept the latest from the common-component
stream, and deliver to the product stream.

Cheers,
Geoff


Thanks Geoff. Is there any way to prevent someone who is a member of the
team
who owns the "product stream" from making changes to the common
component and
delivering them to the parent product stream. In other words, make the
common
component read-only in the product stream, so it's only updated in the
common streams?

Brian

Geoffrey Clemm wrote:

Yes, add the common component to all the streams/workspaces that need it.

WRT how to control what configurations of that common component are used
by different streams, I suggest creating a separate
"common-component-stream" for each logical line of development of that
common component.

Then each product stream would have a "promotion" workspace, which has
both the product stream and the "appropriate" common-component-stream as
its flow targets. Someone would then periodically go into the promotion
workspace, accept the latest from the common-component stream, and
deliver to the product stream.

Cheers,
Geoff

Thanks Geoff. Is there any way to prevent someone who is a member of the
team
who owns the "product stream" from making changes to the common
component and
delivering them to the parent product stream. In other words, make the
common
component read-only in the product stream, so it's only updated in the
common streams?

Brian

Yes, add the common component to all the streams/workspaces that need it.

WRT how to control what configurations of that common component are used
by different streams, I suggest creating a separate
"common-component-stream" for each logical line of development of that
common component.

Then each product stream would have a "promotion" workspace, which has
both the product stream and the "appropriate" common-component-stream as
its flow targets. Someone would then periodically go into the promotion
workspace, accept the latest from the common-component stream, and
deliver to the product stream.

Cheers,
Geoff

bgillan wrote:

I looked for a similar posting but don't this this specific case has
been covered. I assume at some point best practices will be collected
somewhere to cover such questions, but in the meantime, I hope someone
can suggest a way to best handle this.

We have a large number (will grow to as large as 40 or so) of
"products" that are developed independently. There are a
handful of files used for building each of these, and they are
identical for each product, at least at this point. The expectation
is that these will change infrequently.

I'm trying to figure out how to best organize components making the
build files common. The source for each "product" will be
contained in a a single component and then associated with a stream
for development. At some point I'm sure we will likely want to spawn
off separate streams for later release development, maintenance
development, etc.

The question is how to incorporate the "common" build files.
My thought is that these should be placed in a separate component.
And update of these perhaps restricted to one or a couple
individuals.

When changes are made to the common files, the change could be made in
a separate dedicated stream and baselined. We may or may not want
those changes picked up by the individual product. What would be the
easiest way to control this? Add the common component to each
"product" stream, specifying the desired baseline of the
common component to be used. And if a change is made to the common
component that we do desire to be adopted in the product stream,
simple update the product stream and replace the common component
baseline with the new desired baseline? And, how can we control
update of the common component if it's included in several
"product" streams?

I hope this makes sense.

Brian

I looked for a similar posting but don't this this specific case has been covered. I assume at some point best practices will be collected somewhere to cover such questions, but in the meantime, I hope someone can suggest a way to best handle this.

We have a large number (will grow to as large as 40 or so) of "products" that are developed independently. There are a handful of files used for building each of these, and they are identical for each product, at least at this point. The expectation is that these will change infrequently.

I'm trying to figure out how to best organize components making the build files common. The source for each "product" will be contained in a a single component and then associated with a stream for development. At some point I'm sure we will likely want to spawn off separate streams for later release development, maintenance development, etc.

The question is how to incorporate the "common" build files. My thought is that these should be placed in a separate component. And update of these perhaps restricted to one or a couple individuals.

When changes are made to the common files, the change could be made in a separate dedicated stream and baselined. We may or may not want those changes picked up by the individual product. What would be the easiest way to control this? Add the common component to each "product" stream, specifying the desired baseline of the common component to be used. And if a change is made to the common component that we do desire to be adopted in the product stream, simple update the product stream and replace the common component baseline with the new desired baseline? And, how can we control update of the common component if it's included in several "product" streams?

I hope this makes sense.

Brian

harryk wrote:

First, apologies for being UCM/stream rookie, which I think would help
my understanding. But I have played a bit with the Jazz CM a bit and
have some questions.

1) If I create a snapshot for my workspace in the Pending Changes view
(ala 2.1 in Multi-Stream Development doc), I see new baselines for all
the components in that Stream. Also, a 'Show Snapshot' on the on the
workspace shows the shapshot. But a 'Show Snapshot' on the Stream
(in Streams -> <streamname>) does not list it. So, are
there separate snapshots for streams and for workspaces? If so, do
both add a baseline to the components in that stream? And then, how
do I snapshot a stream? So in general what is the best practice for
using snapshots? Are they there to simply add a blanket baseline to
all the contained components?

Technically we could allow creating a snapshot of the stream, but since
it's a shared resource, that is others are delivering to it actively, it
could change underfoot at any time. If you really want to capture a good
state of a stream it's less error prone to configure _your_ repository
workspace with the configuration you want then take a snapshot. A
snapshot is then remembered with the repository workspace and will have
_exactly_ the configuration you want it to be. No one can modify it
underfoot. Any repository workspace or stream can remember a snapshot,
so you can from the snapshots view move a blessed snapshot to a stream.

For our own selfhosting, the only snapshots we generally care about are
those created in the builds. Everything is build driven, meaning that if
I want to reproduce a build, I would open the build result and create a
stream/repo workspace from the snapshot. So we don't actually create and
associate snapshots with stream much.

2) The 'Show History' for an artifact shows the work items that
changed it, but no baselines/snapshots. I relate this view to a CC
version tree. So, first I'd also like to see the metainformation -
baselines, snapshots - marking version of this item. And then second
I believe that data is as interesting in a linear form and am not sure
a a table is the best representation. It is interesting to see how it
changed over workitems and possibly phases/milestones/etc. Something
closer to what I can create with a CC version tree with a decent
branching strategy that follows my change process.

You can see the baselines for a stream/repo workspace by selecting "Show
Baselines" on the component or when viewing the history for a workspace
select the "Show Baselines" button from the views toolbar. You can
compare or replace at the baseline level, or see the change-sets within
them.

The file level history we show in Jazz is by default scoped to the
current history. So we don't show all possible states of the file in
other repository workspaces with whom you don't share the history. This
means that if someone on your team is modifying the file in their
repository workspace you won't see it until you accept that change-set.
We find this to be the most common use of history, to see what you have
and allows you to compare, replace, revert at that level. If you want to
see everything, then switch to the all in repository mode using the
History view toolbar.

It's a typical CC user reaction to want a complete version tree. Our
initial thought was to keep things simpler to start and provide a
history view which supports the most common scenarios. If you are using
a version tree to ask "is this version of the file in release X".
Instead of showing the baselines as tags on the file history, you could
pick the change-set which includes the file and see if it exists in the
baseline you are looking for. I'd be really interested to hear user
level scenarios that you miss from the version tree.

3) A single change can span multiple components (e.g., HTML/DB/Java).
Is there a way to group all the change sets for a work items (which
could consist of hierarchical work items) and deliver them together,
forcing a deliver/accept that is all or nothing? Right now it seems
like we accept change sets individually, which could cause errors or
misunderstandings. Am I confused? Or is there a Jazz practice I am
missing here? I beleive this is related to 2) above in that - I
think - individual change sets are less interesting than the work
item, or baseline, that groups them.

When you deliver or accept change-sets which span components the
operation is atomic. If you want to deliver at a higher ganularity, you
can group the change-sets into baselines and deliver the baselines. On
the other end, you'll see incoming baselines in the Pending Change view
and can simply accept them all without even looking at the change-sets
within them. Someone can always accept change-sets individually if they
want, but it can cause problems. The best practice is to accept the
incoming baselines and not cherry pick from them.

Thanks in advance for straightening out my confusion.

It may of added to your confusion, but hopefully help a bit ;)

Cheers,
Jean-Michel