It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Guidelines | FAQ
Follow this question
Question details

×42,875
×1,588
×889
×75
×38
×23
×23
×4

question asked: Apr 01 '22, 11:11 a.m.
question was seen: 1,337 times
last updated: Apr 04 '22, 7:34 a.m.

Related questions

RTC 6.0.6.1 - Source Control - Components and streams in global context

0
Glyn Costello (140●3●4●54) | asked Apr 01 '22, 11:11 a.m.
Hi all,

I have a global config structure for requirements, tests, etc. with several global (and local) components.

I'm trying to understand how this applies to source control streams and workspaces.

If I have a top level global component "Product A" with an SCM stream and component "Product A Documentation"

then I have a global component underneath product A called "Component 1" with an SCM stream and component "Component 1 documentation"

How should these then be aligned with SCM streams, target flows and workspaces?

In GCM:
Global Stream: PRODUCT A
> CCM Stream: Product A Documentation
>> CCM Component: Product A
> Global Stream: COMPONENT 1
>> CCM Stream: Component 1 Documentation
>>> CCM Component: Component 1

If I have a Workspace which has the "Product A Component" flowing to "Product A Documentation", is it ok to add "Component 1" to this workspace? Does it need its own workspace? Where should it flow to?

One answer

Most liked answers ↑|Newest answers|Oldest answers

0
permanent link
David Honey (1.8k●1●7) | answered Apr 04 '22, 4:54 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
From a GCM point of view, it's ok to have a hierarchy such as the one shown below. The [...] denotes the associated component, and (...) the application that owns that configuration. 
   Product A stream [A] (GC)
        Product A documentation stream [DOCA] (CCM)
        Component 1 Stream [1] (GC)  
            Component 1 documentation stream [DOC1] (CCM)
In EWM SCM, each of the SCM streams belongs to a different component, so there is no component skew.
As far as EWM SCM is concerned, how you organize your flow targets is down to you and how you want to manage those SCM streams. Perhaps others with EWM SCM experience of this type of setup can comment on how they have organized this for their needs.
Comments
Glyn Costello commented Apr 04 '22, 5:41 a.m.
Thanks

In order to add another component in SCM which is part of the same project but in a different level in the hierarchy, do I create a new stream in SCM for that SCM component? Then add that stream to the global component in the hierarchy?

It's just I know SCM also can have structured components, but I assume I just ignore this if I'm using GCM.

Also, if I'm using Global Configuration, I also shouldn't put two SCM components in the same stream if they are intended to be used at different levels of the GCM hierarchy (to avoid skew)?
Glyn Costello commented Apr 04 '22, 7:07 a.m.
Also, in SCM, if I have the two components and each component has its own stream, if I then add both components to my workspace, do I then need to explicitly specify the flow target for each component using the "scope" feature?

This seems like a frustrating extra step? If I leave just the "top level" stream in the workspace flow target, it seems to set the second component's flow target to the top level, even though that component is not part of that stream. So confusing, maybe I'm just not getting something when working with multiple components. 

Within a Workspace:
Top level component changes should flow to the top level stream
Component A changes should flow to the Component A stream
Component B changes should flow to Component B stream

In GCM:
Each of these streams are different configurations in the same GC heirarchy.
Ralph Schoon commented Apr 04 '22, 7:11 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

As far as I am aware, the flow target is completely orthogonal to GCM. GCM does not care about the flow targets. The flow target concept is used in integration scenarios, where you have one or more development streams and integration streams. A developer would flow with the development stream, keeping the stream and the workspace consistent and up to date. The developer can then change the flow target to the integration stream. This reveals the difference between the current workspace and the integration stream. There might be incoming changes and they need to be merged with the outgoing ones. The merge is then delivered to the integration stream. Changing the flow target back to the development stream allows to deliver the merge work.

Ralph Schoon commented Apr 04 '22, 7:34 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

With respect to workspaces, streams and components in SCM: you organize the stream as you desire. Components are a container concept that allows to modularize the code. you use components based on architecture and dependencies. As far as I am aware a flat stream can only have a component only configured once. EWM supports hierarchical components that can be used to break down systems. You can have the same component in the hierarchy multiple times as far as I can tell. But this will create issues with loading these components due to overlap. I have only limited experience with EWM SCM and GCM, but you can organize streams your component in GCM different from how they are organized in EWM. I think it depends on what you want to express.  

Component Skew is, when two components are in the same GC that are on different configurations (baselines).

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.