Hi,

In RTC if multiple developers' Repository work spaces are connected to the same stream then if a developer delivers a change-set it immediately appears in the incoming bay of all other developers. I think it should appear in the incoming bay only when a baseline is created (like rebase to a baseline in UCM). Otherwise all other developers may end up accepting change-sets that may not lead to a stable build. Why RTC not like UCM?

Thanks!

You can set up a stream pattern for this.

Developers deliver to Staging Stream but accept from Blessed Stream.
Integrator accepts from Staging Stream, and if the build is good, delivers to Blessed Stream.

We are working on additional features in this area to add automation to make this type of collaboration easier to set up and maintain.

Hope this helps

On 2011/02/08 3:38, theju wrote:

In RTC if multiple developers' Repository work spaces are connected to
the same stream then if a developer delivers a change-set it
immediately appears in the incoming bay of all other developers. I
think it should appear in the incoming bay only when a baseline is
created (like rebase to a baseline in UCM). Otherwise all other
developers may end up accepting change-sets that may not lead to a
stable build. Why RTC not like UCM?

Some teams have taken the approach of never delivering anything that
will break the build, so that delivered change sets are always safe to
accept into other developers' workspaces. You still want to run a build
after a delivery, but you assume that the build will be successful
rather than assume that it might fail.

One technique that really helps with this approach is for developers to
always run a personal build before delivering. That essentially
recreates the integration build that will be run after delivering, and
is very effective at testing in advance whether or not the delivery will
break the build.

This approach won't work for all teams. (For example, the build might
take too long for personal builds to be practical.) But if it does work
for your team, I highly recommend it.

--
David Olsen
IBM Rational

The pending changes view makes it very clear whether a baseline is
available or just a set of unbaselined change sets. A user can then
easily select whether they want to accept just the baselined changes, or
all of the changes.

This information is important to give the team members an early warning
that there are unbaselined changes that have been delivered to the
stream. In particular, I highly recommend that every project use the
3.0 "must be caught up to stream before deliver" pre-condition (to avoid
breaking the stream by a deliver). In this case, a developer will have
to merge in these changes before delivering, so they should be made
aware of that as soon as possible.

This is particularly important when they have created a change set that
creates a branch in files that have been modified by another team
member, in which case they need to be made aware of that as soon as
possible.

So although having an intermediate staging stream (as described by John)
is certainly possible, I would recommend against it for most projects.

Also note that UCM allows you to rebase with changes from the
integration stream, and does not require you to rebase on a baseline.
So RTC is actually consistent with UCM in this regard.

Cheers,
Geoff



On 2/8/2011 6:38 AM, theju wrote:

Hi,

In RTC if multiple developers' Repository work spaces are connected to
the same stream then if a developer delivers a change-set it
immediately appears in the incoming bay of all other developers. I
think it should appear in the incoming bay only when a baseline is
created (like rebase to a baseline in UCM). Otherwise all other
developers may end up accepting change-sets that may not lead to a
stable build. Why RTC not like UCM?

Thanks!