Best way to create a duplicate component
I am am new to RTC and its concepts, and I would like to know the recommended approach to the following scenario.
I have Project A, represented by Stream A, which contains many components, including a key component X. I want to start Project B, as Stream B, which will have all the same components as A, except X, which will be replaced by a new component Y. I would like the code for Y to use X as a base. Future changes to X are not critical to getting into Y, but I would like changes to all the other components in A to be reflected in B (or vice versa).
If I just duplicate Stream A to create B, my understanding is that this duplicates all the components. Is this correct? If so, this doesn't seem like the proper approach, as changes to the other components are not automatically reflected. Am I using streams correctly? Should I do something like create a Stream A-B for everything but X and Y, and/or a Stream X-only and duplicate it to create Stream Y-only?
Thanks.
I have Project A, represented by Stream A, which contains many components, including a key component X. I want to start Project B, as Stream B, which will have all the same components as A, except X, which will be replaced by a new component Y. I would like the code for Y to use X as a base. Future changes to X are not critical to getting into Y, but I would like changes to all the other components in A to be reflected in B (or vice versa).
If I just duplicate Stream A to create B, my understanding is that this duplicates all the components. Is this correct? If so, this doesn't seem like the proper approach, as changes to the other components are not automatically reflected. Am I using streams correctly? Should I do something like create a Stream A-B for everything but X and Y, and/or a Stream X-only and duplicate it to create Stream Y-only?
Thanks.
3 answers
I would create a duplicate from the stream. Then create a repository workspace that flows to the new stream and load it. Then unshare the project(s) from component x without delivering. Then I would remove component x and create a new component y, then share the initial code with y.
This is not the only solution. There are numerous ways how you can get the initial code into Y and remove X and replace it with Y in the duplicated stream, I guess.
This is not the only solution. There are numerous ways how you can get the initial code into Y and remove X and replace it with Y in the duplicated stream, I guess.
Yes, the way to handle this is to create a Stream A and a Stream B.
But do not create a new component Y. Just use component X in both
streams ... each stream will have its own configuration of component X.
The only issue that you face is how to get Stream A and Stream B to see
the same configurations of the non-X components.
The easiest approach to set up is to just have a workspace that
periodically accepts non-X changes from both Stream A and Stream B, and
then delivers the result to both Stream A and Stream B.
But this approach increases the likelihood that parallel changes to
non-X components will need to be merged.
Another approach is for each Project B workspace to flow with Stream A
for all non-X components and flow with Stream B only for the X
component. This produces the desired result, but does require manual
set-up of each workspace.
The best approach would be work item 127541: "Allow a stream to share a
component from another stream." If this were supported, you could just
have every non-X component in Stream B be "shared" with Stream A. If
this is what you'd want, please feel free to add a comment to this work
item, indicating your interest/support.
Cheers,
Geoff
On 2/13/2012 12:08 PM, vandrunenan wrote:
But do not create a new component Y. Just use component X in both
streams ... each stream will have its own configuration of component X.
The only issue that you face is how to get Stream A and Stream B to see
the same configurations of the non-X components.
The easiest approach to set up is to just have a workspace that
periodically accepts non-X changes from both Stream A and Stream B, and
then delivers the result to both Stream A and Stream B.
But this approach increases the likelihood that parallel changes to
non-X components will need to be merged.
Another approach is for each Project B workspace to flow with Stream A
for all non-X components and flow with Stream B only for the X
component. This produces the desired result, but does require manual
set-up of each workspace.
The best approach would be work item 127541: "Allow a stream to share a
component from another stream." If this were supported, you could just
have every non-X component in Stream B be "shared" with Stream A. If
this is what you'd want, please feel free to add a comment to this work
item, indicating your interest/support.
Cheers,
Geoff
On 2/13/2012 12:08 PM, vandrunenan wrote:
I am am new to RTC and its concepts, and I would like to know the
recommended approach to the following scenario.
I have Project A, represented by Stream A, which contains many
components, including a key component X. I want to start Project B,
as Stream B, which will have all the same components as A, except X,
which will be replaced by a new component Y. I would like the code
for Y to use X as a base. Future changes to X are not critical to
getting into Y, but I would like changes to all the other components
in A to be reflected in B (or vice versa).
If I just duplicate Stream A to create B, my understanding is that
this duplicates all the components. Is this correct? If so, this
doesn't seem like the proper approach, as changes to the other
components are not automatically reflected. Am I using streams
correctly? Should I do something like create a Stream A-B for
everything but X and Y, and/or a Stream X-only and duplicate it to
create Stream Y-only?
Thanks.
The best approach would be work item 127541: "Allow a stream to share a
component from another stream." If this were supported, you could just
have every non-X component in Stream B be "shared" with Stream A. If
this is what you'd want, please feel free to add a comment to this work
item, indicating your interest/support.
Yes, this is what I would want for this scenario. Thanks, I will add a comment.