Merging two streams

hi,

in my case we have one project with 2 teams both team working on same source code files but different modules.
We created 2 stream and associated with the respective teams

Stream 1 is owned by Team1
Stream 2 is owned by Team2

but at some later stages they want to merge both the streams.

what is the better way to do this? any thoughts

Regards,
Qaiser

You can deliver changes from Stream 1 to Stream 2 and vice versa to keep each other in sync. The flow target for a workspace can be changed to the other stream so you can deliver any changes.

A better workflow would be creating a third stream for integration. When Team 1 has stable changes to release for Team 2 to consume, one of the Team 1 members can change flow targets to the integration stream and deliver the changes. Then a member of Team 2 can change flow targets to integration and accept those changes and deliver them to Team 2's stream. From there, Team 2 can accept the changes into their own workspaces.

The person in charge of accepting changes from integration can also set up a separate repository workspace and only track the workspace (ie. don't load any components). This allows the developer to accept/deliver change sets from/to the integration stream without loading any content.

In order to merge two streams:
- switch the flow target of your workspace on one stream to be the other
stream
- accept all incoming changes from the other stream
- resolve any branch conflicts
- if you want to keep using the other stream, deliver changes to the
other stream
- switch the flow target of your workspace back to the original stream
- deliver changes to the original stream

Cheers,
Geoff

qaiserislam wrote:

hi,

in my case we have one project with 2 teams both team working on same
source code files but different modules.
We created 2 stream and associated with the respective teams

Stream 1 is owned by Team1
Stream 2 is owned by Team2

but at some later stages they want to merge both the streams.

what is the better way to do this? any thoughts

Regards,
Qaiser

In order to merge two streams:
- switch the flow target of your workspace on one stream to be the other
stream
- accept all incoming changes from the other stream
- resolve any branch conflicts
- if you want to keep using the other stream, deliver changes to the
other stream
- switch the flow target of your workspace back to the original stream
- deliver changes to the original stream

Cheers,
Geoff

hi,
i tried the steps you described but whenever i change the workflow of my workspace to other stream and deliver the changes; new component is created in target stream instead of merging in existing component. i even tried creating the component with same name in both streams but same happened i.e. new component with same name created

regards,
Qaiser

Hi Tim,

What is the advantage of having a third integration stream? I usually
advocate "use the smallest number of constructs that will get the job
done", so I always look for a compelling reason for adding a new stream.

Similarly, if the two streams are to be "merged", then I usually
advocate just having a developer use a development workspace to do the
merge, because they will need to get the files loaded:
- if there are any conflicts
- so they can get an IDE build to verify the merge builds

so using an extra workspace would often require loading another file area.

Cheers,
Geoff

tmok wrote:

qaiserislamwrote:
hi,
in my case we have one project with 2 teams both team working on
same source code files but different modules.
We created 2 stream and associated with the respective teams

Stream 1 is owned by Team1
Stream 2 is owned by Team2

but at some later stages they want to merge both the streams.

what is the better way to do this? any thoughts

Regards,
Qaiser

You can deliver changes from Stream 1 to Stream 2 and vice versa to
keep each other in sync. The flow target for a workspace can be
changed to the other stream so you can deliver any changes.

A better workflow would be creating a third stream for integration.
When Team 1 has stable changes to release for Team 2 to consume, one
of the Team 1 members can change flow targets to the integration
stream and deliver the changes. Then a member of Team 2 can change
flow targets to integration and accept those changes and deliver them
to Team 2's stream. From there, Team 2 can accept the changes into
their own workspaces.

The person in charge of accepting changes from integration can also
set up a separate repository workspace and only track the workspace
(ie. don't load any components). This allows the developer to
accept/deliver change sets from/to the integration stream without
loading any content.

It has to be the "same" component in both streams not just one with similar/same names. Start with one stream and two components in it. Then duplicate that stream (without creating new components). Then create a repository workspace from that second stream (again without creating new components, just clone the ones from the stream, which is the default behavior).

At this point you'll have 2 streams and 1 repo workspace, all with two components in them. Now follow the instructions Geoff provided and you should be able to merge/flow changes.

It has to be the "same" component in both streams not just one with similar/same names. Start with one stream and two components in it. Then duplicate that stream (without creating new components). Then create a repository workspace from that second stream (again without creating new components, just clone the ones from the stream, which is the default behavior).

At this point you'll have 2 streams and 1 repo workspace, all with two components in them. Now follow the instructions Geoff provided and you should be able to merge/flow changes.

it worked thanks for all your support :)

Oops, it's about merging the streams. I got confused with merging changes from the two streams. I thought it would be easier if more streams are added later and changes have to be merged together for a build.

Hi Tim,

What is the advantage of having a third integration stream? I usually
advocate "use the smallest number of constructs that will get the job
done", so I always look for a compelling reason for adding a new stream.

Similarly, if the two streams are to be "merged", then I usually
advocate just having a developer use a development workspace to do the
merge, because they will need to get the files loaded:
- if there are any conflicts
- so they can get an IDE build to verify the merge builds

so using an extra workspace would often require loading another file area.

Cheers,
Geoff

tmok wrote:

qaiserislamwrote:
hi,
in my case we have one project with 2 teams both team working on
same source code files but different modules.
We created 2 stream and associated with the respective teams

Stream 1 is owned by Team1
Stream 2 is owned by Team2

but at some later stages they want to merge both the streams.

what is the better way to do this? any thoughts

Regards,
Qaiser

You can deliver changes from Stream 1 to Stream 2 and vice versa to
keep each other in sync. The flow target for a workspace can be
changed to the other stream so you can deliver any changes.

A better workflow would be creating a third stream for integration.
When Team 1 has stable changes to release for Team 2 to consume, one
of the Team 1 members can change flow targets to the integration
stream and deliver the changes. Then a member of Team 2 can change
flow targets to integration and accept those changes and deliver them
to Team 2's stream. From there, Team 2 can accept the changes into
their own workspaces.

The person in charge of accepting changes from integration can also
set up a separate repository workspace and only track the workspace
(ie. don't load any components). This allows the developer to
accept/deliver change sets from/to the integration stream without
loading any content.