Hi all,
I just wondering what is the point of flow targets between streams?
I mean, having flow targets between remote workspace and streams does makes sense for me.
You can change flow target of a remote workspace in order to deliver or accept change sets to another stream. But I don't really understand change flow between streams. You can't deliver change sets directly from a stream to other stream ... or I miss something.
I think that I need some one that explains me that feature.

Thanks!

Regards

Andrs

It was initially implemented as a display of intent. Users that deliver changes from their workspaces to the stream can see the eventual flow path for their changes. It doesn't guarantee that the changes will flow to the stream's flow target but it's an indicator of where it is likely to flow (i.e. someone else is probably responsible for taking the changes from that stream and delivering it to the stream's flow targets).

In RTC 3.0.1, you can show a stream in pending changes and it needs a flow target to show changes between the stream and its current flow target.

Hi,

I just wanted to point out that it is possible to deliver Change Sets from one stream into another stream.

Let's say you have 2 streams. One is the "Dev" stream and the other is the "QA" stream. The "QA" stream is used for the QA builds and those are candidates for production releases. So, you don't always want everything from the "Dev" stream in the "QA" stream. On the build server you would have a "QA build" workspace that has a Flow Target that is pointing to the "QA" stream.

You can set up a personal QA workspace so that it has 2 Flow Targets in it. One for the "Dev" Stream and one for the "QA" stream. (Yes, you can do this). I would not do it in a workspace used for a build, because that causes a build error (in v2.0.0.x).

When the Dev team delivers to the project, they deliver to the "Dev" stream. You can then set your workspace to point to the "Dev" stream. You will see the Incoming changes from the Dev team. At this point, you can pick only the Change Sets that you want (or select all of them). After accepting the Change sets, you will change the Flow Target of your QA workspace to point to the "QA" stream. This will now show that you have a "Deliver" action which contains the Change Sets you accepted earlier. If you deliver these Changes sets, the "QA build" workspace will see those Change Sets as Incoming Changes. Now you can Accept those Incoming Changes and run a QA build, if you want.

The above is a brief overview of how we control what goes into our builds here. Sometimes, whatever the Dev team is delivering is OK to go into a "QA build". At other times you may want to pick and choose what goes from Dev into QA. This process helps us to do that. I gave a presentation at Innovate 2011 that shows this process in more detail. Let me know if you would like more info on it and I can provide it to you.

Thanks,

- Walter

Hi all,
I just wondering what is the point of flow targets between streams?
I mean, having flow targets between remote workspace and streams does makes sense for me.
You can change flow target of a remote workspace in order to deliver or accept change sets to another stream. But I don't really understand change flow between streams. You can't deliver change sets directly from a stream to other stream ... or I miss something.
I think that I need some one that explains me that feature.

Thanks!

Regards

Andrs