If you ever think you might want to merge files between these two
components(even a some distant point in the future), they should be one
component, not two.

Cheers,
Geoff

GeeTee wrote:

There are two ways of working with components in RTC:

http://i649.photobucket.com/albums/uu214/gwenthomas/ComponentsIssue.jpg

Firstly, We have two development lines Dev and R09 running in
parallel. They are both using the same components: C1 and C2. As
changes are made to these components on both development lines, we
end up with different baselines of the same component.

The second way would be if we still have two development lines Dev and
R09 running in parallel. However we create one component C1 for Dev,
and the same component C1 for R09. Likewise for C2. Independent work
is then carried out on each component.

So my question is: What are the implications of each way of working?
What is lost or gained in choosing one or the other?

If you ever think you might want to merge files between these two
components(even a some distant point in the future), they should be one
component, not two.

Cheers,
Geoff

+++

Yes - but why ? What does having them in the same component allow you to do ? Or to put it another way - if they are in different components - what does that disallow you to do ?

Thanks,
Martin.

MartinBailey wrote:

Yes - but why ? What does having them in the same component allow
you to do ? Or to put it another way - if they are in different
components - what does that disallow you to do ?

If you ever want to merge the changes from one stream into the other,
then using one component will make that easier. You might want to merge
changes from one stream into another if one of the streams is for
maintenance releases and the other stream is for the next major release.
In that case it is common to merge the maintenance stream into the major
release stream at some point, so that all the bug fixes get into the
next major release.

If you used one component, RTC will help you with the merging. It will
identify all the change sets that need to be merged and will bring up a
merge editor when there are conflicts.

If you used two components, RTC won't help you at all with the merge.
You will have to identify the changes that need to be merged and will
have to manually make those changes in the target stream.

To be very explicit, if two streams share the same component, and then
changes to the same file have been made in both streams, when you merge
one stream to the other, RTC will detect those parallel changes, and
give you 3-way merge support to make the merge easy.

If instead you make a copy of the code in a second component, and then
merge the streams, RTC has no way of noticing whether or not a file has
been changed in parallel, and even if you can discover that manually,
the best it can do is a "two way merge", which cannot tell you which
side has the "new changes" and which side has the "original code" (which
is what a 3-way merge does for you).

Cheers,
Geoff

David Olsen wrote:

MartinBailey wrote:
Yes - but why ? What does having them in the same component allow
you to do ? Or to put it another way - if they are in different
components - what does that disallow you to do ?

If you ever want to merge the changes from one stream into the other,
then using one component will make that easier. You might want to merge
changes from one stream into another if one of the streams is for
maintenance releases and the other stream is for the next major release.
In that case it is common to merge the maintenance stream into the major
release stream at some point, so that all the bug fixes get into the
next major release.

If you used one component, RTC will help you with the merging. It will
identify all the change sets that need to be merged and will bring up a
merge editor when there are conflicts.

If you used two components, RTC won't help you at all with the merge.
You will have to identify the changes that need to be merged and will
have to manually make those changes in the target stream.