It's all about the answers!

Ask a question

Easy means for multiple streams to share a component and alw


Brian Gillan (3215330) | asked Feb 12 '09, 5:38 p.m.
We have a common component to be used across numerous features (over a
dozen) that are developed independently. So, we will have a stream for
each feature that contains a component for the feature itself, as well
as the common component. The desire is that the latest updates to the
common component are used and captured in a snapshot of the stream,
regardless of what stream it's updated in. Is there an easy way to
achieve this without having to manually flow changes between streams?
The only case where we might want the common component changes isolated
to the containing stream is for hot-fixes.

Brian

11 answers



permanent link
Geoffrey Clemm (30.1k33035) | answered Feb 15 '09, 3:18 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
One way is to not have a copy of the common component in each feature
stream, but rather have a separate stream for the common component.
The in your workspace, you would get your feature components from your
feature stream, and your common component from the common component stream.

Cheers,
Geoff

Brian Gillan wrote:
We have a common component to be used across numerous features (over a
dozen) that are developed independently. So, we will have a stream for
each feature that contains a component for the feature itself, as well
as the common component. The desire is that the latest updates to the
common component are used and captured in a snapshot of the stream,
regardless of what stream it's updated in. Is there an easy way to
achieve this without having to manually flow changes between streams?
The only case where we might want the common component changes isolated
to the containing stream is for hot-fixes.

Brian

permanent link
Brian Gillan (3215330) | answered Feb 16 '09, 8:08 p.m.
Geoffrey Clemm wrote:
One way is to not have a copy of the common component in each feature
stream, but rather have a separate stream for the common component.
The in your workspace, you would get your feature components from your
feature stream, and your common component from the common component stream.

Cheers,
Geoff
Thanks Geoff, When I try that, it seems to have the same effect as

adding a component to a stream.... it adds the component, but at the
latest baseline. And when I then make changes to the component in a
separate stream, they aren't reflected in the workspace I had added it
to (unless I did something wrong).

Brian

permanent link
Geoffrey Clemm (30.1k33035) | answered Feb 16 '09, 9:38 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Changes aren't reflected in a workspace until you accept them. In
particular, the changes to that component should have showed up in your
Pending Changes view for that workspace, from which you can accept them.

Cheers,
Geoff

Brian Gillan wrote:
Geoffrey Clemm wrote:
One way is to not have a copy of the common component in each feature
stream, but rather have a separate stream for the common component.
The in your workspace, you would get your feature components from your
feature stream, and your common component from the common component
stream.

Cheers,
Geoff
Thanks Geoff, When I try that, it seems to have the same effect as
adding a component to a stream.... it adds the component, but at the
latest baseline. And when I then make changes to the component in a
separate stream, they aren't reflected in the workspace I had added it
to (unless I did something wrong).

Brian

permanent link
Brian Gillan (3215330) | answered Feb 17 '09, 9:18 a.m.
Geoffrey Clemm wrote:
Changes aren't reflected in a workspace until you accept them. In
particular, the changes to that component should have showed up in your
Pending Changes view for that workspace, from which you can accept them.

Cheers,
Geoff

No pending changes appeared. Here's my use case:

- Existing "feature" stream with two components, and corresponding
workspace loaded on my client.
- I created a new stream and my "common" component, created a general
Eclipse project with a folder and single file, added it to source
control, selecting the newly created "common" component
- Updated by existing "feature" workspace, adding "Component in another
repository workspace or stream", selecting the newly created "common"
component. It gets added and appears to be at the last baseline of that
comonent.
- Make a change to the file in the common component, deliver the change.
The change appears in the stream containing the "common" component, but
no pending changes for the "feature" workspace.

Any thoughts?

Thanks, Brian

permanent link
Geoffrey Clemm (30.1k33035) | answered Feb 17 '09, 2:58 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Oops. I meant "additional flow target for your workspace", not
"additional flow target for your stream".

Cheers,
Geoff


Geoffrey Clemm wrote:
You don't want to add the common component to your workspace, but rather
you want to add the stream containing the common component as an
additional "flow target" for your stream. So your workspace will have
two streams as targets: the feature stream and the common stream.

Note that to see pending changes from both targets, you either have to
periodically make each of those streams the "current" target of the
workspace, or to see pending changes from both streams at the same time,
you have to set the
Team->Jazz_Source_Control->Changes:Flow_Targets:Show_all preference.

Cheers,
Geoff



Brian Gillan wrote:
Geoffrey Clemm wrote:
Changes aren't reflected in a workspace until you accept them. In
particular, the changes to that component should have showed up in
your Pending Changes view for that workspace, from which you can
accept them.

Cheers,
Geoff

No pending changes appeared. Here's my use case:
- Existing "feature" stream with two components, and corresponding
workspace loaded on my client.
- I created a new stream and my "common" component, created a general
Eclipse project with a folder and single file, added it to source
control, selecting the newly created "common" component
- Updated by existing "feature" workspace, adding "Component in
another repository workspace or stream", selecting the newly created
"common" component. It gets added and appears to be at the last
baseline of that comonent.
- Make a change to the file in the common component, deliver the change.
The change appears in the stream containing the "common" component,
but no pending changes for the "feature" workspace.

Any thoughts?

Thanks, Brian

permanent link
Geoffrey Clemm (30.1k33035) | answered Feb 17 '09, 2:58 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
You don't want to add the common component to your workspace, but rather
you want to add the stream containing the common component as an
additional "flow target" for your stream. So your workspace will have
two streams as targets: the feature stream and the common stream.

Note that to see pending changes from both targets, you either have to
periodically make each of those streams the "current" target of the
workspace, or to see pending changes from both streams at the same time,
you have to set the
Team->Jazz_Source_Control->Changes:Flow_Targets:Show_all preference.

Cheers,
Geoff



Brian Gillan wrote:
Geoffrey Clemm wrote:
Changes aren't reflected in a workspace until you accept them. In
particular, the changes to that component should have showed up in
your Pending Changes view for that workspace, from which you can
accept them.

Cheers,
Geoff

No pending changes appeared. Here's my use case:
- Existing "feature" stream with two components, and corresponding
workspace loaded on my client.
- I created a new stream and my "common" component, created a general
Eclipse project with a folder and single file, added it to source
control, selecting the newly created "common" component
- Updated by existing "feature" workspace, adding "Component in another
repository workspace or stream", selecting the newly created "common"
component. It gets added and appears to be at the last baseline of that
comonent.
- Make a change to the file in the common component, deliver the change.
The change appears in the stream containing the "common" component, but
no pending changes for the "feature" workspace.

Any thoughts?

Thanks, Brian

permanent link
Andrew Hoo (1.0k1) | answered Feb 17 '09, 4:58 p.m.
JAZZ DEVELOPER
Once you have the common component in its own stream, you can remove that component from your 'feature' repository workspace. Then create a repository workspace that corresponds to the 'Common' stream and load it.

So, you'll have two repository workspaces being tracked by the Pending Changes view (Common and Feature-A), while your team mate who works on a different feature will have his own repository workspaces (Common, and Feature-B), and so forth.


On Tue, 17 Feb 2009 09:11:57 -0500, Brian Gillan <bgillan> wrote:

Geoffrey Clemm wrote:
Changes aren't reflected in a workspace until you accept them. In
particular, the changes to that component should have showed up in your
Pending Changes view for that workspace, from which you can accept them.
Cheers,
Geoff

No pending changes appeared. Here's my use case:
- Existing "feature" stream with two components, and corresponding
workspace loaded on my client.
- I created a new stream and my "common" component, created a general
Eclipse project with a folder and single file, added it to source
control, selecting the newly created "common" component
- Updated by existing "feature" workspace, adding "Component in another
repository workspace or stream", selecting the newly created "common"
component. It gets added and appears to be at the last baseline of that
comonent.
- Make a change to the file in the common component, deliver the change.
The change appears in the stream containing the "common" component, but
no pending changes for the "feature" workspace.

Any thoughts?

Thanks, Brian




--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

permanent link
Geoffrey Clemm (30.1k33035) | answered Feb 17 '09, 11:48 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Note that one advantage of Andrew's approach (having two workspaces)
over the approach I suggested (having one workspace with two flow
targets) is that you can see all pending changes with the default "show
only the current flows" behavior (with one workspace, you'd have to
select "show all flows").

Cheers,
Geoff

Andrew Hoo wrote:
Once you have the common component in its own stream, you can remove
that component from your 'feature' repository workspace. Then create a
repository workspace that corresponds to the 'Common' stream and load it.

So, you'll have two repository workspaces being tracked by the Pending
Changes view (Common and Feature-A), while your team mate who works on a
different feature will have his own repository workspaces (Common, and
Feature-B), and so forth.


On Tue, 17 Feb 2009 09:11:57 -0500, Brian Gillan <bgillan@us.ibm.com
wrote:

Geoffrey Clemm wrote:
Changes aren't reflected in a workspace until you accept them. In
particular, the changes to that component should have showed up in
your Pending Changes view for that workspace, from which you can
accept them.
Cheers,
Geoff

No pending changes appeared. Here's my use case:
- Existing "feature" stream with two components, and corresponding
workspace loaded on my client.
- I created a new stream and my "common" component, created a general
Eclipse project with a folder and single file, added it to source
control, selecting the newly created "common" component
- Updated by existing "feature" workspace, adding "Component in
another repository workspace or stream", selecting the newly created
"common" component. It gets added and appears to be at the last
baseline of that comonent.
- Make a change to the file in the common component, deliver the change.
The change appears in the stream containing the "common" component,
but no pending changes for the "feature" workspace.

Any thoughts?

Thanks, Brian




permanent link
Brian Gillan (3215330) | answered Mar 03 '09, 4:00 p.m.
I got distracted for a couple weeks on other issues and have come back to this.

I'm still struggling with getting the right model set up for what we want to achieve here. I've set up two streams as suggested, one containing a "feature" component, and the other containing the "common" component. I've created and loaded a workspace for each.

Now comes my build process. I created my build workspace, initially containing the "feature" component. But, I also want the common included in my build. When I add my common component to the build workspace, my Pending Changes view now shows a change where the common component will be delivered to my "feature" stream. I don't think I want t deliver this, as it would add my common component back into my feature stream.

The desire is that my build will contain the latest changes delivered to my feature stream, and common stream. And, in the process of building, would create a snapshot that would save the configuration of both components for what I'm building. Is this not possible? Would I have to load my common stream separately during the build process? If that's the case, I can never capture a complete configuration in RTC of what's being built.

Brian

permanent link
Jean-Michel Lemieux (2.5k11) | answered Mar 03 '09, 4:59 p.m.
JAZZ DEVELOPER
Yes this is possible, and we call this our "nightly build" pattern. In your build workspace add both the "feature" and "common" components. From the workspace editor in the flow target section, add a flow target for each of the streams that contains "the latest" for that component and restrict "scope" the flow so that only that component flows from it's stream. This will give you the following configuration:

Stream Feature
feature
ui
doc

Stream Common
common
tests
doc

Nightly Build Workspace
feature <-> Stream Feature:feature (scoped)
common <-> Stream Common:common (scoped)

When the build runs it will accept from the flow targets specified in the build workspace and will grab the latest from two different streams.

Jean-Michel

Your answer


Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.