It's all about the answers!

Ask a question

Delivering to 2 streams simultaneously


Przemyslaw Bozowski (111) | asked Dec 01 '10, 10:20 a.m.
edited Jun 21 '16, 10:20 a.m. by David Lafreniere (4.8k7)
I have 2 streams: DevStream (Development), and MainStream (Maintenance) + there are two users: DevUser (DevStream User) and MainUser (MainStream User)

Is it possible to configure these two streams in a way that:
- when MainUser delivers change sets to MainStream, the change sets also appear in DevStream,
- but, when DevUser delivers change sets to DevStream, the change sets don't show up in MainStream?

Is it doable in RTC to deliver a change set to two streams at the same time? If yes, what about conflicts resolution?

Comments
Philippe Krief commented Dec 01 '10, 10:25 a.m. | edited Jun 21 '16, 10:28 a.m.
JAZZ DEVELOPER

As far as I know, this kind of behavior is not supported.
Could you explain your use case?


Przemyslaw Bozowski commented Dec 01 '10, 10:35 a.m. | edited Jun 21 '16, 10:29 a.m.
As far as I know, this kind of behavior is not supported.
Could you explain your use case?



My team is working on an interim stream, which needs to be synchronized with maintanance stream. We can do this single-handedly by changing flow target of the interim stream to maintenance stream and accept all the change sets. But we wanted to automate this procedure, so when somebody delivers to maintenance stream, the change sets appears in "incoming list" of our interim stream too, so this is our usecase.

4 answers



permanent link
Geoffrey Clemm (30.1k33035) | answered Dec 03 '10, 12:23 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
A result of this "file linking" feature of some SCM systems is you are
modifying a large number of configurations without ever having seen or
tested those configurations.

The alternative approach used by RTC makes sure that each owner of a
stream can define what are the "deliver conditions" for delivering to
that stream, and that no code is delivered to that stream unless those
deliver conditions are met.

Cheers,
Geoff

On 12/1/2010 1:08 PM, shonuff wrote:
My team (and every team I know of) has exactly this concern. Our
current SCM tool allows us to establish links between the same file
in different streams (releases). This link indicates that the files
are identical, and when the user delivers the change to one stream he
must either deliver them to all linked streams (simply by listing the
other streams in a text box) or explicitly break the link.

Right now it appears that switching from our current SCM tool to RTC
would force each developer to explicitly manage these relationships.
This can more than double the cost of the deliver, as the number of
streams is not limited to one each for development and maintenance.
It also seems to increase the likelihood of a file falling
incorrectly out of sync between various streams.

We are willing to work to make the transition (to RTC) possible (I'm
told it may be possible to create a pre or post action that compares
the file across streams and potentially performs the deliver in those
other streams), but if there is a supported/suggested method, I'd very
much appreciate being made aware of it.

permanent link
Tim Mok (6.6k38) | answered Dec 02 '10, 9:14 a.m.
JAZZ DEVELOPER
Switching to "all flows" mode requires additional work for guys from maintanance. The usecase was that they deliver to their stream and development stream. If one of them delivers to component "A" from maintenance stream, and forgets to deliver to component "A" from development stream, the streams become unsynchronized and even nobody knows that something bad happenned.

It's not the exact solution to the use case but at the very least the developer can see that there are outgoing changes to another stream. Pending Changes also has a deliver all out going changes action. With all flows view, the change sets would be delivered to all flow targets with one action.

Unfortunately, I think you'll need something custom, using API, to check incoming deliveries to a stream and check if it needs to be delivered to another stream.

Although, I think it is good that users have to explicitly deliver to a stream. All the responsibility of knowing what is flowed to a stream is put on the developer and they can handle any merges that may be required when dealing with development and maintenance streams.

permanent link
Tim Mok (6.6k38) | answered Dec 01 '10, 2:32 p.m.
JAZZ DEVELOPER
I have 2 streams: DevStream (Development), and MainStream (Maintenance) + there are two users: DevUser (DevStream User) and MainUser (MainStream User)

Is it possible to configure these two streams in a way that:
- when MainUser delivers change sets to MainStream, the change sets also appear in DevStream,
- but, when DevUser delivers change sets to DevStream, the change sets don't show up in MainStream?

Is it doable in RTC to deliver a change set to two streams at the same time? If yes, what about conflicts resolution?
You can set up your workspace with all the flow targets that the workspace should flow to. In Pending Changes view, you can switch it to "all flows" mode. When delivering, you can deliver to all the flow targets easily this way. However, it may be a little confusing because components are shown multiple times in Pending Changes (once for every flow target) so you can potentially deliver to a subset of the flow targets.

There isn't an automated way of doing it though. It wouldn't be guaranteed that change sets will apply cleanly to one stream when it depends on change sets from the other stream.

Comments
Przemyslaw Bozowski commented Dec 02 '10, 4:23 a.m. | edited Jun 21 '16, 10:30 a.m.
I have 2 streams: DevStream (Development), and MainStream (Maintenance) + there are two users: DevUser (DevStream User) and MainUser (MainStream User)

Is it possible to configure these two streams in a way that:
- when MainUser delivers change sets to MainStream, the change sets also appear in DevStream,
- but, when DevUser delivers change sets to DevStream, the change sets don't show up in MainStream?

Is it doable in RTC to deliver a change set to two streams at the same time? If yes, what about conflicts resolution?

You can set up your workspace with all the flow targets that the workspace should flow to. In Pending Changes view, you can switch it to "all flows" mode. When delivering, you can deliver to all the flow targets easily this way. However, it may be a little confusing because components are shown multiple times in Pending Changes (once for every flow target) so you can potentially deliver to a subset of the flow targets.

There isn't an automated way of doing it though. It wouldn't be guaranteed that change sets will apply cleanly to one stream when it depends on change sets from the other stream.

Switching to "all flows" mode requires additional work for guys from maintanance. The usecase was that they deliver to their stream and development stream. If one of them delivers to component "A" from maintenance stream, and forgets to deliver to component "A" from development stream, the streams become unsynchronized and even nobody knows that something bad happenned.


permanent link
Brian Murray (1153) | answered Dec 01 '10, 12:54 p.m.
My team (and every team I know of) has exactly this concern. Our current SCM tool allows us to establish links between the same file in different streams (releases). This link indicates that the files are identical, and when the user delivers the change to one stream he must either deliver them to all linked streams (simply by listing the other streams in a text box) or explicitly break the link.

Right now it appears that switching from our current SCM tool to RTC would force each developer to explicitly manage these relationships. This can more than double the cost of the deliver, as the number of streams is not limited to one each for development and maintenance. It also seems to increase the likelihood of a file falling incorrectly out of sync between various streams.

We are willing to work to make the transition (to RTC) possible (I'm told it may be possible to create a pre or post action that compares the file across streams and potentially performs the deliver in those other streams), but if there is a supported/suggested method, I'd very much appreciate being made aware of it.

Comments
Walter Mansur commented Dec 01 '10, 1:31 p.m. | edited Jun 21 '16, 10:30 a.m.

We do something similar using "Flow Targets". As an example, for a particular project, we have one "workspace" that is used for builds. Sometimes, we want to "isolate" changes made by the development team and get them delivered into a separate stream than the normal stream that is used for the builds. Then we build with just those changes (using the appropriate build definition, of course). The use of Flow Targets allows us to do this. It is not very hard to do.


Does this sound sort of like what you want to do? If so, let me know and I can explain it in more detail.

- Walter

My team (and every team I know of) has exactly this concern. Our current SCM tool allows us to establish links between the same file in different streams (releases). This link indicates that the files are identical, and when the user delivers the change to one stream he must either deliver them to all linked streams (simply by listing the other streams in a text box) or explicitly break the link.

Right now it appears that switching from our current SCM tool to RTC would force each developer to explicitly manage these relationships. This can more than double the cost of the deliver, as the number of streams is not limited to one each for development and maintenance. It also seems to increase the likelihood of a file falling incorrectly out of sync between various streams.

We are willing to work to make the transition (to RTC) possible (I'm told it may be possible to create a pre or post action that compares the file across streams and potentially performs the deliver in those other streams), but if there is a supported/suggested method, I'd very much appreciate being made aware of it.

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.