Automatic flow between streams
We moved to a new project and migrated some of our workitems. We also created a new stream that is based on a synchronized stream from the old project. The new stream has the old stream as a target flow , but it doesn't seem to be that the changes flow between the streams. My questions are
1. How can automate the flow of changes between two streams?
2. Can you turn an existing stream to a synchronized stream?
3. What are the implications of associating our old stream with the new project? Does old workitems change-set linkage will still work?
1. How can automate the flow of changes between two streams?
2. Can you turn an existing stream to a synchronized stream?
3. What are the implications of associating our old stream with the new project? Does old workitems change-set linkage will still work?
13 answers
1. No. Changes only flow from a source stream to a target stream if you
accept the changes from the source stream into a workspace, and deliver
the changes from the workspace into the target stream.
2. No, creating a synchronized stream always creates a new jazz stream.
Why would you need/want to turn an existing stream into a synchronized
stream?
3. The team area that owns a stream determines the process that is
applied to operations on the stream. It has no effect on the change-set
linkage (so they still work).
Cheers,
Geoff
abaror wrote:
accept the changes from the source stream into a workspace, and deliver
the changes from the workspace into the target stream.
2. No, creating a synchronized stream always creates a new jazz stream.
Why would you need/want to turn an existing stream into a synchronized
stream?
3. The team area that owns a stream determines the process that is
applied to operations on the stream. It has no effect on the change-set
linkage (so they still work).
Cheers,
Geoff
abaror wrote:
We moved to a new project and migrated some of our workitems. We also
created a new stream that is based on a synchronized stream from the
old project. The new stream has the old stream as a target flow ,
but it doesn't seem to be that the changes flow between the streams.
My questions are
1. How can automate the flow of changes between two streams?
2. Can you turn an existing stream to a synchronized stream?
3. What are the implications of associating our old stream with the
new project? Does old workitems change-set linkage will still work?
We use a synchronized stream on one project , now our team is moving to a new project, we can move the workitems to the new project , but not the stream. It seems that you can move the stream only between teams in the same project
My guess it that we should create a new synchronized stream in the new project?
My guess it that we should create a new synchronized stream in the new project?
1. No. Changes only flow from a source stream to a target stream if you
accept the changes from the source stream into a workspace, and deliver
the changes from the workspace into the target stream.
2. No, creating a synchronized stream always creates a new jazz stream.
Why would you need/want to turn an existing stream into a synchronized
stream?
3. The team area that owns a stream determines the process that is
applied to operations on the stream. It has no effect on the change-set
linkage (so they still work).
Cheers,
Geoff
abaror wrote:
We moved to a new project and migrated some of our workitems. We also
created a new stream that is based on a synchronized stream from the
old project. The new stream has the old stream as a target flow ,
but it doesn't seem to be that the changes flow between the streams.
My questions are
1. How can automate the flow of changes between two streams?
2. Can you turn an existing stream to a synchronized stream?
3. What are the implications of associating our old stream with the
new project? Does old workitems change-set linkage will still work?
You can move a stream to a new project area ... you just have to be
connected to both the old and the new project areas (only project areas
to which you are connected show up in the "Browse" dialog box, when you
change the owner of a stream).
Cheers,
Geoff
abaror wrote:
connected to both the old and the new project areas (only project areas
to which you are connected show up in the "Browse" dialog box, when you
change the owner of a stream).
Cheers,
Geoff
abaror wrote:
We use a synchronized stream on one project , now our team is moving
to a new project, we can move the workitems to the new project , but
not the stream. It seems that you can move the stream only between
teams in the same project
My guess it that we should create a new synchronized stream in the new
project?
gmclemmwrote:
1. No. Changes only flow from a source stream to a target stream if
you
accept the changes from the source stream into a workspace, and
deliver
the changes from the workspace into the target stream.
2. No, creating a synchronized stream always creates a new jazz
stream.
Why would you need/want to turn an existing stream into a
synchronized
stream?
3. The team area that owns a stream determines the process that is
applied to operations on the stream. It has no effect on the
change-set
linkage (so they still work).
Cheers,
Geoff
abaror wrote:
We moved to a new project and migrated some of our workitems. We
also
created a new stream that is based on a synchronized stream from
the
old project. The new stream has the old stream as a target flow ,
but it doesn't seem to be that the changes flow between the
streams.
My questions are
1. How can automate the flow of changes between two streams?
2. Can you turn an existing stream to a synchronized stream?
3. What are the implications of associating our old stream with
the
new project? Does old workitems change-set linkage will still
work?
I guess before posting, I should have tried to hit "save" after changing
the project area of the stream (:-).
Note that a stream is a very lightweight object, so duplication is cheap
(I assume you wanted to do the "move" to keep the history of the stream
easily accessible in the new project).
Cheers,
Geoff
jlemieux wrote:
the project area of the stream (:-).
Note that a stream is a very lightweight object, so duplication is cheap
(I assume you wanted to do the "move" to keep the history of the stream
easily accessible in the new project).
Cheers,
Geoff
jlemieux wrote:
Actually, we don't allow moving a stream between project areas. It's
not supported by the platform just yet. But you can duplicate a
stream and assign the duplicated to another other project if you
like.
Jean-Michel
Can I duplicate a synchronized stream to another project and expect the CC synchronization to work and preserve all history?
Actually, we don't allow moving a stream between project areas. It's not supported by the platform just yet. But you can duplicate a stream and assign the duplicated to another other project if you like.
Jean-Michel
Good question. You can just create a new synchronized stream in the new
project area (against the same ClearCase stream/branch), and the CC
synchronization will work, but it will take time to initialize, and the
history of previous synchronized stream would not be carried over to the
new synchronized stream.
I've submitted workitem 73404 requesting the ability to reparent a
stream into a different team area.
Cheers,
Geoff
abaror wrote:
project area (against the same ClearCase stream/branch), and the CC
synchronization will work, but it will take time to initialize, and the
history of previous synchronized stream would not be carried over to the
new synchronized stream.
I've submitted workitem 73404 requesting the ability to reparent a
stream into a different team area.
Cheers,
Geoff
abaror wrote:
Can I duplicate a synchronized stream to another project and expect
the CC synchronization to work and preserve all history?
jlemieuxwrote:
Actually, we don't allow moving a stream between project areas. It's
not supported by the platform just yet. But you can duplicate a
stream and assign the duplicated to another other project if you
like.
Jean-Michel
1. No. Changes only flow from a source stream to a target stream if you
accept the changes from the source stream into a workspace, and deliver
the changes from the workspace into the target stream.
If this is the case, can you describe the indended Use Case of the feature that allows users to set the flow target of one stream to a different stream?
Is it merely so that on a Flow Diagram, one can show the team's intended use of the two streams, namely that changes made in the first are routinely also delievered to the second?
Thanks!
Yes, currently that stream-stream flow link is just for documentation
(has no semantics). I have submitted a work item, suggesting that we
give that link some semantics (workitem 86817).
Cheers,
Geoff
travman wrote:
(has no semantics). I have submitted a work item, suggesting that we
give that link some semantics (workitem 86817).
Cheers,
Geoff
travman wrote:
gmclemmwrote:
1. No. Changes only flow from a source stream to a target stream if
you
accept the changes from the source stream into a workspace, and
deliver
the changes from the workspace into the target stream.
If this is the case, can you describe the indended Use Case of the
feature that allows users to set the flow target of one stream to a
different stream?
Is it merely so that on a Flow Diagram, one can show the team's
intended use of the two streams, namely that changes made in the
first are routinely also delievered to the second?
Thanks!
Yes, currently that stream-stream flow link is just for documentation
(has no semantics). I have submitted a work item, suggesting that we
give that link some semantics (workitem 86817).
Would this work (I don't have a sandbox and build server to play with):
1. Make two streams, "Dev Stream," which all the developers target, and "Dev Stream's Flow Target Stream", which no one targets.
2. Edit the "Dev Stream," and add "Dev Stream's Flow Target Stream" as a flow target.
3. Create a workspace for a build, targeting "Dev Stream's Flow Target Stream."
4. Check the "Accept changes before load" checkbox, and do something innocuous in the build, as in nothing.
5. Schedule the build every 30 minutes.
Would changes flow from stream to stream in that case?
page 1of 1 pagesof 2 pages