How to restrict the flow target (between streams) to make sure the flow happens in only on direction?

Venkittarayan Chandrasekharan (11●1●1) | asked Jan 16 '13, 3:13 p.m.

Hiya there,

I'm new RTC, but have started to like the tool.

I'm in a dilema.

I'll explain my scenario.

I've 2 streams, StreamA and StreamB

2 different team have created workspace and connected to their respective streams and started their work.

I've created a flow target in StreamA to StreamB.

I want the changes to move from StreamA to StreamB and not the otherwise.

The problem i'm facing is that when i created the flow target, from A to B, the changes delivered to the streamB is also coming into StreamA

Now in the pending changes view, StreamA <-> StreamB item, if the same file present in incoming and outgoing, I'm not able to do either and not able to merge as well.

I want a way to restrict the flow of code so that code can move only from StreamA to StreamB.

Is there any way to do this in RTC?

Thanks,

Venkit

2 answers

Most liked answers ↑|Newest answers|Oldest answers

permanent link

Tim Mok (6.6k●3●8) | answered Jan 16 '13, 4:12 p.m.
JAZZ DEVELOPER
edited Jan 16 '13, 4:15 p.m.

https://jazz.net/jazz/resource/itemName/com.ibm.team.workitem.WorkItem/160738 - It sounds like you want directed flows. This is currently not supported but there is a story item describing what you want.

The ability to show a stream in your Pending Changes view only allows for accept and deliver actions. There is no support to perform merges so you'll have to do that by using a repository workspace. Once you've resolved conflicts in the repository workspace, you can deliver the changes to the stream.

http://pic.dhe.ibm.com/infocenter/clmhelp/v3r0m1/topic/com.ibm.team.scm.doc/topics/t_flow_changes_to_stream.html - It's also mentioned in the documentation that only non-conflicting flows are supported in stream-to-stream flows.

Comments

Venkittarayan Chandrasekharan commented Jan 16 '13, 4:59 p.m.

Hi Tim,

This info saved me a lot of time.

So ideally if developers need to check in to both the streamsA and StreamB, thne they'd have to do it manually.

Connect to the first one and checkin and deliver and connect to the StreamB and resolve any conflicts and checkin and deliver.

hmm... i guess there is no other way that can be used for the problem at hand.

Thanks mate

Tim Mok commented Jan 16 '13, 5:09 p.m.

JAZZ DEVELOPER

Yes, you'll have to deliver using a workspace to both streams. Although, you've seen that streams can be tracked in Pending Changes and allows delivery. My team uses this for flowing changes between our team stream and integration stream. It's not as useful if you're trying to flow changes from a current release stream to an older release stream where the code has diverged, which may cause conflicts.

It sounds like your streams will have conflicts to be resolved so it's probably best to use a workspace to deliver changes from stream A to stream B.

Also, stream flow targets are only used when flowing changes in Pending Changes. The default flow target for a stream is the target when you show the stream in Pending Changes. Adding a flow target to a stream doesn't imply that changes will automatically flow to the target. You still need someone to perform the delivery.

permanent link

w h (19●18●24) | answered Oct 31 '13, 12:01 p.m.
edited Oct 31 '13, 12:22 p.m.

THANK YOU. This is the only artifact I've found that addresses this issue clearly. This is must reading for anyone looking to implement a parallel development, multiple release Change Management and Release strategy.

This is a common use case for any team over 5 people. The Stream / Workspace workaround forces some unintuitive and un-natural flow diagrams, or the creation of additional hoops to make the flow diagram understandable for the average user.

This is a huge gap for RTC SCM, especially in comparison to other SCM tools. It doesn't seem like the Stream buys me any value; it seems more logical to just work with private and public workspaces if the tool would allow that.

Comments

Tim Mok commented Oct 31 '13, 1:06 p.m.

JAZZ DEVELOPER

A stream is essentially a public workspace. The main difference between a stream and a workspace is that users can deliver to a stream. You cannot deliver to another user's workspace (you wouldn't want to mess up the user's configuration and put his/her sandbox out-of-sync). The use of a workspace to flow changes is required to handle conflicts and that would require loading content.

w h commented Oct 31 '13, 1:30 p.m.

Thanks Tim. What are your thoughts on a public Workspace where users flow target their private Workspace changes to it? To me it seems like this provides the functionality I need (reverse changesets, snapshots, delivery, etc) without the overhead of a Stream. It seems the Workspace has a lot of overlap with the minimum set of Stream functionality in addition to functionality only the Workspace can provide (non trivial merging, one direction delivery, "load as" files, etc)

It's all about the answers!

Related questions

How to restrict the flow target (between streams) to make sure the flow happens in only on direction?

2 answers

Your answer