Flowing from private workspaces to shared workspaces

You may want to read the article on multi-stream development: https://jazz.net/library/article/40

It sounds like you're unnecessarily using a workspace for integrating changes before delivering to the integration stream. Unless I'm misunderstanding your setup, I think you want to deliver changes from the development workspace to a feature stream or a collaboration stream. It's a stream for developers working on a feature to collaborate and share changes. Then you want those changes to flow to the integration stream when stable. It would eventually flow like this:

Developer workspace -> Shared stream -> Integration stream

It sounds like your problem is getting the changes from integration into developer workspaces.

The basic idea is a user has a workspace with all the changes from the shared stream. When changing flow target of the developer workspace to the integration stream, the shared stream changes can be delivered. Also, changes in integration can be accepted into the developer workspace. It flows like this:

Developer workspace -> Integration stream

When the user changes the flow target back to the shared stream, he can deliver the changes from integration. Then all the other developers flowing with the shared stream can pick up the changes from integration. The flow would go back to normal like this:

Developer workspace -> Shared stream

There has to be a workspace to carry the changes and send them to the desired target streams.

So a possible problem in your situation is the flow target on the developer workspace isn't collaborating with a target that has the changes you expect or it already has the changes.

Maybe I'm not clear on how your streams and workspaces are set up with respect to the flow targets but it sounds like you're not seeing changes because of a wrong flow target.

Hi Tim,

Thanks for your reply. I had already read the article you indicated before I posted my question and I'm afraid it doesn't provide an answer.

The whole point of using shared workspaces rather than streams at the feature level is so that users do not ever have to change their flow targets. I'm trying to achieve a situation similar to the one we currently have with UCM ClearCase.

In fact, the IBM/Rational training handbook for configuring projects in RTC V3.0 has a diagram indicating exactly the setup I've created but I'm finding that in practice it doesn't work. Delivering from developer workspaces to shared workspaces, delivering from the shared workspaces to the integration stream and accepting changes from the integration stream onto the shared workspaces all works fine but the final step of accepting changes from the shared workspaces onto the developer workspaces does not seem to work and changing the flow target of a developer workspace would not help in this respect because there may be changes on the integration stream that are not yet in the shared workspace and which the developer does not want to pick up.

Thanks,

Simon.

Hi Tim,

Thanks for your reply. I had already read the article you indicated before I posted my question and I'm afraid it doesn't provide an answer.

The whole point of using shared workspaces rather than streams at the feature level is so that users do not ever have to change their flow targets. I'm trying to achieve a situation similar to the one we currently have with UCM ClearCase.

In fact, the IBM/Rational training handbook for configuring projects in RTC V3.0 has a diagram indicating exactly the setup I've created but I'm finding that in practice it doesn't work. Delivering from developer workspaces to shared workspaces, delivering from the shared workspaces to the integration stream and accepting changes from the integration stream onto the shared workspaces all works fine but the final step of accepting changes from the shared workspaces onto the developer workspaces does not seem to work and changing the flow target of a developer workspace would not help in this respect because there may be changes on the integration stream that are not yet in the shared workspace and which the developer does not want to pick up.

Thanks,

Simon.

Hi Simon

I recall seeing info about delivering to another workspace, tried to do this and never managed to get it to work (but I didn't try very hard). What might be possible is accepting changes from another workspace - but that does not solve your problem.

anthony

Hi Simon

I recall seeing info about delivering to another workspace, tried to do this and never managed to get it to work (but I didn't try very hard). What might be possible is accepting changes from another workspace - but that does not solve your problem.

anthony

Good point. You can only deliver to another of your own workspaces. You cannot deliver to another user's workspace because it could unknowingly alter a workspace that they've loaded and cause out of sync issues without the user's consent. Accept from another user's workspace is allowed.

I would still alter the workflow to use a stream to collect the work for a feature and then deliver those changes to integration with a workspace.

I would still alter the workflow to use a stream to collect the work for a feature and then deliver those changes to integration with a workspace.

Hi Tim,

Please could you elaborate on how you would do this?

Many thanks,

Simon.

I would still alter the workflow to use a stream to collect the work for a feature and then deliver those changes to integration with a workspace.

Hi Tim,

Please could you elaborate on how you would do this?

Many thanks,

Simon.

Actually I think I can imagine what you mean. I'm going to give it a try.

Thanks,

Simon.