Change flow from stream to stream
Change flow between a stream and workspace is pretty intuitive, with change set flow and conflict resolution behaving as expected.
However, the flow editor allows you to flow one stream to another stream. What does that mean? when would change sets flow and how would conflicts be resolved?
I had assumed change sets would have to flow through a workspace to get from one stream to another.
Also how do you implement a one-way flow between streams if a workspace declares two streams as flow targets?
However, the flow editor allows you to flow one stream to another stream. What does that mean? when would change sets flow and how would conflicts be resolved?
I had assumed change sets would have to flow through a workspace to get from one stream to another.
Also how do you implement a one-way flow between streams if a workspace declares two streams as flow targets?
3 answers
I speculate that there are no semantics behind the stream/stream flow
declaration (i.e. it's effectively a comment indicating that changes
should flow between these streams), but we'll need someone from the SCM
team to verify/correct that speculation.
WRT the last question (implementing one-way flow), currently, you would
need to do this manually, by making each of the source-only streams
current and then accepting changes from them, and then switching back to
making the target stream current, and then doing a deliver.
There is an enhancement request to allow the user to declare this
one-way flow (workitem 33114). In particular, this workitem would allow
you to declare that all flow targets are "sources", but only the current
flow target is a "target" (i.e. one-way flow from the sources to the
target). (But note that this enhancement is not currently planned to be
implemented.)
Cheers,
Geoff
jim.islandtraining.com wrote:
declaration (i.e. it's effectively a comment indicating that changes
should flow between these streams), but we'll need someone from the SCM
team to verify/correct that speculation.
WRT the last question (implementing one-way flow), currently, you would
need to do this manually, by making each of the source-only streams
current and then accepting changes from them, and then switching back to
making the target stream current, and then doing a deliver.
There is an enhancement request to allow the user to declare this
one-way flow (workitem 33114). In particular, this workitem would allow
you to declare that all flow targets are "sources", but only the current
flow target is a "target" (i.e. one-way flow from the sources to the
target). (But note that this enhancement is not currently planned to be
implemented.)
Cheers,
Geoff
jim.islandtraining.com wrote:
Change flow between a stream and workspace is pretty intuitive, with
change set flow and conflict resolution behaving as expected.
However, the flow editor allows you to flow one stream to another
stream. What does that mean? when would change sets flow and how
would conflicts be resolved?
I had assumed change sets would have to flow through a workspace to
get from one stream to another.
Also how do you implement a one-way flow between streams if a
workspace declares two streams as flow targets?
Just FYI - I am at a customer site on a RTC pilot project PoC and was asked this exact same question today. They do this today (have automatic flow of fixes) using ClearCase, and would like the same functionality in RTC. Or, rather, they think they want it - we're still trying to figure out what the best way (rather than just how they do it today) to do things is.
I thought that flowing a stream to another stream might work, but can't figure out how to "deliver" changes from one stream to another.
Gary
I thought that flowing a stream to another stream might work, but can't figure out how to "deliver" changes from one stream to another.
Gary
When you say "auto-flow of fixes using ClearCase", I assume this means
they are using dynamic views, with config-specs that automatically see
particular branches?
If so, no, they can't do that with RTC, because RTC does not support
dynamic views.
But you can argue that such automatic change flow can be risky, in case
there actually were conflicts (the config-spec will in that case just
pick the change that comes from the first rule in the config-spec that
matches, rather than detecting a merge conflict).
So you have explicitly flow changes between streams by accepting all
changes from both streams into a workspace, and then delivering the
result to the destination stream (see my preceding note in this thread
to see how to do that).
Cheers,
Geoff
garymu wrote:
they are using dynamic views, with config-specs that automatically see
particular branches?
If so, no, they can't do that with RTC, because RTC does not support
dynamic views.
But you can argue that such automatic change flow can be risky, in case
there actually were conflicts (the config-spec will in that case just
pick the change that comes from the first rule in the config-spec that
matches, rather than detecting a merge conflict).
So you have explicitly flow changes between streams by accepting all
changes from both streams into a workspace, and then delivering the
result to the destination stream (see my preceding note in this thread
to see how to do that).
Cheers,
Geoff
garymu wrote:
Just FYI - I am at a customer site on a RTC pilot project PoC and was
asked this exact same question today. They do this today (have
automatic flow of fixes) using ClearCase, and would like the same
functionality in RTC. Or, rather, they think they want it - we're
still trying to figure out what the best way (rather than just how
they do it today) to do things is.
I thought that flowing a stream to another stream might work, but
can't figure out how to "deliver" changes from one stream
to another.
Gary