https://jazz.net/jazz/resource/itemName/com.ibm.team.workitem.WorkItem/160738

It sounds like you want directed flows (see work item).

Developers can also create a repository workspace for each release stream. I do this with my own development because it's easier to do than sifting through a bunch of change sets to find the one I want to deliver. I only change flow targets when handling an integration stream or a side stream for experimental work. Those kinds of streams would have less changes and I likely care about all the outgoing/incoming changes instead of a few out of a large set.

I believe what you really want is to mark a given change-set as
something you don't want to flow to a particular stream. In particular,
when scanning through the change sets in 7.0, some you want to deliver,
and others you want to "ignore", and you want the destination stream to
remember that you have decided to ignore those change-sets in that
particular stream. In ClearCase, you would do this by creating a merge
hyper-link, saying "treat this version as if it had been merged to this
branch". We need something similar in RTC.

This functionality is requested in work item 102223, as an "ignore"
operation. There is a variant of this request in work item 159380,
which is a "reject" operation. The difference between "ignore" and
"reject" is that an "ignore" applies only to the workspace to which you
applied the ignore, while the "reject" is recorded in the change
history, which means if you accept changes from that workspace, you also
accept the "reject" information (whereas you wouldn't accept "ignore"
information).

So if you are interested in either "ignore" or "reject" (or both),
please add a comment to the appropriate work item(s).

Cheers,
Geoff

On 11/18/2011 11:08 AM, scottchapman wrote:

For reference, I am working on a project with a few streams that
represent major timelines for our project. For example, we have a 7.0
stream where we are doing fixes to our 7.0 release, and ongoing
development for 8.0 is being done in our 8.0 stream. And generally
speaking all our changes that we deliver to 7.0 we want to also be
delivered to 8.0. And we have created some scripts which essentially
do the auto-merging. While we could come up with some convention
where we mark change sets in some way so that the script could ignore
them, they will always show up when developers change their flow
target and so there is always a risk that it would get delivered.

So, I thought I had a process for this that could work; basically
deliver the change set and then immediately reverse it. But I have
found that when the change set leads to a conflict things get messy
enough that I can't figure out how to do what I am trying to do...

So, as a concrete example, we have some files which contain version
specific information. So, when we are producing a new point release
for 7.0.1 for example we would make the change in the 7.0 stream, but
do not want those changes to manifest in the 8.0 stream.

I am not seeing a good way to do this in 2.0.0.x

Although directed flows are a very good thing, I don't think they would
solve Scott's use case, because he wants the stream to remember that he
didn't want to flow certain change sets (while flowing others).

Cheers,
Geoff

On 11/18/2011 11:38 AM, tmok wrote:

https://jazz.net/jazz/resource/itemName/com.ibm.team.workitem.WorkItem/160738

It sounds like you want directed flows (see work item).

Developers can also create a repository workspace for each release
stream. I do this with my own development because it's easier to do
than sifting through a bunch of change sets to find the one I want to
deliver. I only change flow targets when handling an integration
stream or a side stream for experimental work. Those kinds of streams
would have less changes and I likely care about all the
outgoing/incoming changes instead of a few out of a large set.

Although directed flows are a very good thing, I don't think they would
solve Scott's use case, because he wants the stream to remember that he
didn't want to flow certain change sets (while flowing others).

Cheers,
Geoff

That was just a suggestion since the directed flows work item already has someone else asking for the feature preventing delivery to the wrong release stream. Maybe there's something similar that could be implemented but would still show the changes. Hiding changes can be confusing if the user wants to accept something and it can't because of a gap. But the change set that fills the gap was ignored. It makes a bit more difficult for the user to understand what's going on.

I'm just not sure if Scott wanted the change sets to be put on an ignore list. All I understood was that change sets shouldn't be accidentally put into a stream where they shouldn't be.

WRT what Scott wanted, I cheated a bit by having a sametime conversation
with Scott (:-). So to confirm, he does want the ability to accept some
of the incoming changes and reject other incoming changes. The
resulting gaps should then be handled by the appropriate selective merge
operation.

Note that this is a very high priority enhancement for RTC, but it
unfortunately didn't quite make the cut for the next release. The plan
item is 170658, and there are a large number of related work items
(follow the "related" links from the plan item).

Cheers,
Geoff


On 11/18/2011 1:53 PM, tmok wrote:

gmclemmwrote:
Although directed flows are a very good thing, I don't think they
would
solve Scott's use case, because he wants the stream to remember that
he
didn't want to flow certain change sets (while flowing others).

Cheers,
Geoff
That was just a suggestion since the directed flows work item
already has someone else asking for the feature preventing delivery
to the wrong release stream. Maybe there's something similar that
could be implemented but would still show the changes. Hiding changes
can be confusing if the user wants to accept something and it can't
because of a gap. But the change set that fills the gap was ignored.
It makes a bit more difficult for the user to understand what's going
on.

I'm just not sure if Scott wanted the change sets to be put on an
ignore list. All I understood was that change sets shouldn't be
accidentally put into a stream where they shouldn't be.

Can I put up my hand for a 'one way' flow?

I am working with several clients who are using industry models sourced from external authorities (including IBM's IFW and IAA, ACORD, eTOM, IEC CIM etc)

Basically the client brings version X of the external models into an Industry stream and baselines, then delivers that to an Organisation stream. This stream is used by projects to then customise the industry models for their organisation. These changes are delivered back to the Organisation stream to form baselines of the organisation's enterprise models.

The issue I am having is when version X+1 of the external industry model is released and we want to firstly bring those changes into the Industry stream, and then merge them into the Organisation stream. RTC tells me I have changesets that I need to accept from the Organisation stream before it will let me deliver into the Industry stream, but we want the Industry stream to only contain the changes from the external industry body, and to be able to deliver those changes to the Organisation.

A one way flow would work perfectly in this situation

When version X+! of the external industry model is available, you would:
- select or create a workspace that flows only with the Industry stream
- accept all changes from the Industry stream into that workspace
- apply version X+1 of the external models to the sandbox of that workspace.
- checkin and deliver those changes to the Industry stream.

So the Organization stream never comes up in this process.

Cheers,
Geoff

Can I put up my hand for a 'one way' flow?

I am working with several clients who are using industry models sourced from external authorities (including IBM's IFW and IAA, ACORD, eTOM, IEC CIM etc)

Basically the client brings version X of the external models into an Industry stream and baselines, then delivers that to an Organisation stream. This stream is used by projects to then customise the industry models for their organisation. These changes are delivered back to the Organisation stream to form baselines of the organisation's enterprise models.

The issue I am having is when version X+1 of the external industry model is released and we want to firstly bring those changes into the Industry stream, and then merge them into the Organisation stream. RTC tells me I have changesets that I need to accept from the Organisation stream before it will let me deliver into the Industry stream, but we want the Industry stream to only contain the changes from the external industry body, and to be able to deliver those changes to the Organisation.

A one way flow would work perfectly in this situation

When version X+! of the external industry model is available, you would:
- select or create a workspace that flows only with the Industry stream
- accept all changes from the Industry stream into that workspace
- apply version X+1 of the external models to the sandbox of that workspace.
- checkin and deliver those changes to the Industry stream.

So the Organization stream never comes up in this process.

Cheers,
Geoff

Thanks for the reply Geoff!

I am in the process of rebuilding the EMDD PoT internally to use RTC and I trialled it the other day with a client, and hit this right at the end.

What you described is exactly how it was set up, and I can't remember if it's during the workspace delivery or the stream delivery that you see it, but you definitely get stopped at some point.

It may be when you attempt to deliver the new Industry stream baseline to the Organisation stream that it insists you pull the Organisation stream changes back first before you can deliver the new Industry model, and that's not what you want.

Yes, it is likely that you did get stopped when you tried to deliver from the Industry stream to the Organization stream, because there was a merge conflict when the same file was changed in the Industry stream and in the Organization stream. In that case, a merge needs to be performed, and to do a merge, you have to accept the changes from both the Organization stream and the Industry stream into your workspace. But once you do the merge in your workspace, you only deliver the changes to the Organization stream, not to the Industry stream, so the Industry stream continues to contain the correct state of the external industry model.

Cheers,
Geoff

When version X+! of the external industry model is available, you would:
- select or create a workspace that flows only with the Industry stream
- accept all changes from the Industry stream into that workspace
- apply version X+1 of the external models to the sandbox of that workspace.
- checkin and deliver those changes to the Industry stream.

So the Organization stream never comes up in this process.

Cheers,
Geoff

Thanks for the reply Geoff!

I am in the process of rebuilding the EMDD PoT internally to use RTC and I trialled it the other day with a client, and hit this right at the end.

What you described is exactly how it was set up, and I can't remember if it's during the workspace delivery or the stream delivery that you see it, but you definitely get stopped at some point.

It may be when you attempt to deliver the new Industry stream baseline to the Organisation stream that it insists you pull the Organisation stream changes back first before you can deliver the new Industry model, and that's not what you want.