It's all about the answers!

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

×42,856

question asked: Jan 13 '10, 11:20 a.m.
question was seen: 4,167 times
last updated: Jan 13 '10, 11:20 a.m.

Related questions

using streams as flow targets of other streams

0
Hans Egger (6●1●1) | asked Jan 13 '10, 11:20 a.m.
I need some advice on how to use flow targets within RTC efficiently and 'correctly':
My team is working on 3 different releases of a product in parallel. Therefore I assumed we would need 3 streams and appropriate repository workspaces delivering into these streams (lets assume for now that there is just a single component) which is the same for all streams).
A fix done on an older release will most likely, but not always, be needed in the newer release(s). Therefore I had set up the streams as a hierarchy of flow targets (S1 -> S2 -> S3, where S1 is the oldest release) and for each stream for testing a single repository workspace (WS1 -> S1, ...)

Now my expectation was that I could deliver a change set into S1 via WS1 (which works fine) and this change set would automatically flow into S2, where I could accept it or reject it (after having the change built and tested within S1). However changes in S1 do not appear in any way in S2. I can flow the changes from the corresponding workspaces to each of the streams, but none of the changes ever seems to get propagated.

Am I misunderstanding how this is supposed to work or am I missing a vital part here?

Thanks
Hans

One answer

Most liked answers ↑|Newest answers|Oldest answers

0
permanent link
Jose Miguel Ordax Cassa (2.4k●4●126●100) | answered Jan 13 '10, 3:53 p.m.
On 13-Jan-10 5:23 PM, eggerh wrote:
I need some advice on how to use flow targets within RTC efficiently
and 'correctly':
My team is working on 3 different releases of a product in parallel.
Therefore I assumed we would need 3 streams and appropriate
repository workspaces delivering into these streams (lets assume for
now that there is just a single component) which is the same for all
streams).
A fix done on an older release will most likely, but not always, be
needed in the newer release(s). Therefore I had set up the streams as
a hierarchy of flow targets (S1 -> S2 -> S3, where S1 is the
oldest release) and for each stream for testing a single repository
workspace (WS1 -> S1, ...)

Now my expectation was that I could deliver a change set into S1 via
WS1 (which works fine) and this change set would automatically flow
into S2, where I could accept it or reject it (after having the
change built and tested within S1). However changes in S1 do not
appear in any way in S2. I can flow the changes from the
corresponding workspaces to each of the streams, but none of the
changes ever seems to get propagated.

Am I misunderstanding how this is supposed to work or am I missing a
vital part here?

Thanks
Hans


No, AFAIK you are not misunderstanding anything. The point here is that
Flow Target between streams is used just for paint flow diagrams. But it
doesn't promote any change sets.

The way to do it is (just an example):

- Create a Repository Workspace used by the integrator role.
- Connect it to S1 and load the code.
- Change the connection, and connect it to S2.
- Deliver the change you are interested on.

There is an automatic way to do such promotion of code between streams
but it is by SCM CLI (command line), not using the User Interface AFAIK.

You can check other posts in this same forums asking for the same thing.

Regards,

Chemi.

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.