On 2011/01/13 18:08, swatoon wrote:

1. When do we create a new stream? For major enhancements, releases or
for different project phase (Dev stream, SIT stream, UAT stream) or
anything else?

To oversimplify it a little bit (but not too much), you should create a
new stream whenever your team wants to branch your source. Whenever a
team wants to maintain a version of the source that is potentially
different from what is in any other stream, then a new stream should be
created to hold that version or branch of the source. Note that a
stream is for a team wanting to make a public branch where the team will
integrate and gather its work. (A stream shouldn't be used for a
private branch. That's what a repository workspace for. See below.)

2. What are the considering factors to decide if we should create a
new stream or just utilise the suspend/resume feature when parallel
development work is required? (eg, major and minor releases, bug
fixes)

Streams have nothing to do with suspend/resume. Streams are used by
teams to manage what is essentially a branch of the source code.

The primary purpose of suspend/resume (which I think is a fabulous
feature) is for a developer to quickly switch what he is working on
while continuing to use the same repository workspace. (For example,
the developer is in the middle of making a big change. A new bug is
discovered that needs an urgent fix. The developer suspends all the
change sets for the big change, restoring his workspace to match the
stream that it flows with. He makes the bug fix without the big change
getting in the way and delivers it to the stream. Then he resumes his
change sets and continues working on the big change.) Suspend/resume is
just a tool for developers to make their lives easier when they need to
work on two things at once. It shouldn't be part of any official
development process.

3. Am I right to say repository workspace achieve similar objective as
branching? Without this server side workspace, traditional SCM tool
would have to create a new branch for development to be saved on the
server without affecting the main branch.

Repository workspaces can be a way for developers to create their own
private branch, so they can work on something without interfering with
their teammates and still have it stored on the server. Since things on
a private branch don't make it into releases or affect the official
product, the private branch (the repository workspace) should be
regularly merged with the public branch (the stream) on a regular basis
by accepting changes from the stream and delivering changes to the stream.

4. Is it possible to configure multiple repository workspace per user
per stream?

Yes. A user can have any number of repository workspaces, which can all
flow with the same stream. A user having multiple workspaces that flow
with different streams is quite common. A single user having multiple
workspaces that flow with the same stream is less common, but happens
from time to time.

If the different repository workspaces are just different versions of
the same content, then it's not possible to load both of those
repository workspaces into the same Eclipse workspace at the same time
(assuming you are using the Eclipse client). But you could have
multiple Eclipse workspaces, or you could switch between repository
workspaces by unloading one repository workspace and loading the other
one. There are different ways of managing multiple repository
workspaces. You should experiment and see which one works best for you.

I really appreciate some help here to let me understand the concept
better.

RTC SCM is very different from many other SCM systems. It takes some
time and experience to get used to it and to figure out how to use it
well. But I think RTC SCM is very well designed, so it is worth the
effort of learning how to use it.

--
David Olsen
IBM Rational

All of your impressions stated below are correct, i.e. that streams,
repository workspaces, and suspend/resume provide ways of branching, and
that it is possible to provide multiple repository workspaces per user
per stream.

To provide an overview of the forms of branching:
- stream branching: a stream provides a branch at the "team" level.
- repository workspace branching: a workspace provides a fully-featured
personal branch, i.e. you can load it into the file system, track
history, create baselines on it, etc.
- change-set branching: suspending/resuming a change-set in a repository
workspace provides a very lightweight form of branching, where the
change-set itself effectively is the branch.

In terms of deciding which branch mechanism to use, stream vs.
repository workspace branching is usually pretty clear ... do you want
the whole team to use the branch, or is it solely for use by a single
individual. Whether to use a repository workspace or a change-set for a
personal branch is also usually pretty clear ... just use suspend/resume
on change-sets (the lightweight approach), until you need something more
than that, in which case, create a separate personal workspace for the
branch.

Cheers,
Geoff

On 1/13/2011 9:08 PM, swatoon wrote:

Hi,

I am new to RTC and hope to gain some understanding in the concept of
branching in RTC. From what I read so far, RTC's "Streams"
are conceptually similar to branches. Then there is also the
suspend/resume functionality, and the workspace repository which
allows members of a project to perform parallel development as well.

So one question I have is how are streams/workspace repositories
organised for a project?

1. When do we create a new stream? For major enhancements, releases or
for different project phase (Dev stream, SIT stream, UAT stream) or
anything else?
2. What are the considering factors to decide if we should create a
new stream or just utilise the suspend/resume feature when parallel
development work is required? (eg, major and minor releases, bug
fixes)
3. Am I right to say repository workspace achieve similar objective as
branching? Without this server side workspace, traditional SCM tool
would have to create a new branch for development to be saved on the
server without affecting the main branch.
4. Is it possible to configure multiple repository workspace per user
per stream?

I really appreciate some help here to let me understand the concept
better. Thanks very much.

David Olsen wrote:

Repository workspaces can be a way for developers to create their own
private branch, so they can work on something without interfering with
their teammates and still have it stored on the server. Since things on
a private branch don't make it into releases or affect the official
product, the private branch (the repository workspace) should be
regularly merged with the public branch (the stream) on a regular basis
by accepting changes from the stream and delivering changes to the stream.

If you wanted to keep your interference to the absolute mimimum, wouldn't you then remove all flow targets from your workspace definition?

My understanding is that if you don't do that then your delivered change sets would be shown as ready to be accepted by other team members who share the same flow target (stream). Conversely, their delivered change sets would show up as ready to be accepted into your workspace.

Hence, you would only add a stream to your private workspace flow target list when you are again ready to share your changes and get the updates from others.

Is my understanding correct or am I missing something?

Cheers,

Chris

On 2011/01/17 14:08, cnovak wrote:

If you wanted to keep your interference to the absolute minimum,
wouldn't you then remove all flow
targets from your workspace definition?

But you don't want to keep your interference to the absolute minimum. In
one sense, you want to maximize your interference. The more frequently
that you accept and deliver (assuming that your deliveries never break
the product), the less time there will be for incompatibilities to grow
and the less overall effort there will be to integrate changes together.
It is a *lot* easier to merge in a small set of changes than a large
set of changes.

I am a big proponent of continuous integration and have a hard time
imagining working any other way. While having my own repository
workspace is necessary to keep from breaking others while I am working
on a change, I always keep my flow target set to the stream. And I get
nervous if I don't accept other people's changes for more than a day or
if I have undelivered changes of my own that are more than a few days old.

Hence, you would only add a stream to your private workspace flow
target list when you are again ready to share your changes and get
the updates from others.

Getting updates from others should continuously. You should always be
willing to accept changes into your workspace. Sharing your changes
with others should happen frequently, whenever you are confident that
your changes have been sufficiently tested and won't break the product.

--
David Olsen
IBM Rational

It is important to recognize that unlike some SCM systems, which have a
single operation (usually called "checkin") to commit your changes to
the SCM repository, RTC has two operations: "checkin" and "deliver".

You perform "checkin" when you want your changes persisted in the
repository, but don't want them to appear as incoming changes to the
other members of your team (i.e. you want to keep those changes "private").

You perform a separate operation, "deliver", when those changes are
ready to be used by other members of your team (for convenience, there
is a "checkin and deliver" operation, that allows you to do both a
"checkin" and a "deliver" in one request.

With that in mind, comments added below:

On 1/17/2011 5:08 PM, cnovak wrote:

If you wanted to keep your interference to the absolute mimimum,
wouldn't you then remove all flow
targets from your workspace definition?

Flow targets for a workspace do not create any interference, they just
control what show up as incoming/outgoing for that workspace when that
workspace is loaded into the Pending Changes view.

My understanding is that if you don't do that then your delivered
change sets would be shown as ready to be accepted by other team
members who share the same flow target (stream). Conversely, their
delivered change sets would show up as ready to be accepted into your
workspace.

The flow targets of a workspace have no effect on whether or not a
change set shows up as ready to be accepted by other team members who
share the same flow target. It is only when you have actually delivered
a change set to that stream that it shows up as ready to be accepted by
other team members.

Hence, you would only add a stream to your private workspace flow
target list when you are again ready to share your changes and get
the updates from others.

You add a stream to your workspace flow target if you might at some time
share your changes and get the updates. When you are ready to actually
share a particular change, you would "deliver" it.

Cheers,
Geoff

David, I understand the need for continuous integration and sharing changes within a team. There are times, however, when you want to focus on a change/fix/enhancement without being distracted by merges. It sounds, as per Geoff clear explanation, that a check-in without a deliver gives that flexibility. Thank you both for a response.

Regards,

Chris Novak

All of your impressions stated below are correct, i.e. that streams,
repository workspaces, and suspend/resume provide ways of branching, and
that it is possible to provide multiple repository workspaces per user
per stream.

To provide an overview of the forms of branching:
- stream branching: a stream provides a branch at the "team" level.
- repository workspace branching: a workspace provides a fully-featured
personal branch, i.e. you can load it into the file system, track
history, create baselines on it, etc.
- change-set branching: suspending/resuming a change-set in a repository
workspace provides a very lightweight form of branching, where the
change-set itself effectively is the branch.

In terms of deciding which branch mechanism to use, stream vs.
repository workspace branching is usually pretty clear ... do you want
the whole team to use the branch, or is it solely for use by a single
individual. Whether to use a repository workspace or a change-set for a
personal branch is also usually pretty clear ... just use suspend/resume
on change-sets (the lightweight approach), until you need something more
than that, in which case, create a separate personal workspace for the
branch.

Cheers,
Geoff

Sorry to bring this up again, but I'm still a bit confused about best practices.

I've seen the docs refer to using streams in a number of scenarios:

1. versioning of delivered code including major releases and service releases
2. creating stream hierarchies for things such as intermediate build integration levels
3. creating related variants of sets of files

The use of streams for different reasons makes it difficult to understand best practices.

For example, use of streams for versioning purposes seems exactly what snapshots were supposed to be used for. Using streams for intermediate build integration levels seems like that is what workspaces were for. Using streams for creating variant collections (e.g. Product, instrumented variant of product, educational variant of product) seems like the right idea, but if I need to keep streams separated by version and variant, things get confused and if I add a build integration hierarchy of streams to that, it's really confused. So what are the best practices? If we are really supposed to keep all these things separated by streams, what are the best practices for creating and managing them?

Thanks,
Jim

The short answer is that yes, those are three of the reasons to use
multiple streams. Conceptually, a stream is a shared place containing
an evolving configuration of versioned files and directories. So one
reason you need different configurations is that you have different
configurations for different releases. Another is that you have
different configurations for different "quality levels". Another is
that you have different configurations for different "variants" (note
that the difference between a "release" and a "variant" is fairly fuzzy).

Snapshots cannot be used for these purposes because a snapshot does not
"evolve" ... it is a single immutable configuration (so you do use a
snapshot for a particular release, but if you are going to be producing
patches for that release, you'll need a stream, not just a snapshot).

Workspaces cannot be used for these purposes because workspaces are
updated by a single person, while these configurations are normally
maintained by a team (a "shared" configuration). Although if you have a
single user maintaining a release, a build, or a variant, then you
certainly could do so in just a workspace.

As for keeping them straight, you would do so by partitioning them into
the appropriate project and team areas. Having different "types" of
objects to manage slightly different flavors of "evolving
configurations" would be more confusing, especially when in the case of
"releases" and "variants", the distinction is a fuzzy one.

Cheers,
Geoff




On 7/25/2011 3:38 PM, knutson wrote:

Sorry to bring this up again, but I'm still a bit confused about best
practices.

I've seen the docs refer to using streams in a number of scenarios:

1. versioning of delivered code including major releases and service
releases
2. creating stream hierarchies for things such as intermediate build
integration levels
3. creating related variants of sets of files

The use of streams for different reasons makes it difficult to
understand best practices.

For example, use of streams for versioning purposes seems exactly what
snapshots were supposed to be used for. Using streams for
intermediate build integration levels seems like that is what
workspaces were for. Using streams for creating variant collections
(e.g. Product, instrumented variant of product, educational variant
of product) seems like the right idea, but if I need to keep streams
separated by version and variant, things get confused and if I add a
build integration hierarchy of streams to that, it's really confused.
So what are the best practices? If we are really supposed to keep
all these things separated by streams, what are the best practices
for creating and managing them?

Thanks,
Jim

Ok, I understand. But, with this discussion about best practices in using streams, how then are components used for these use scenarios?

The short answer is that yes, those are three of the reasons to use
multiple streams. Conceptually, a stream is a shared place containing
an evolving configuration of versioned files and directories. So one
reason you need different configurations is that you have different
configurations for different releases. Another is that you have
different configurations for different "quality levels". Another is
that you have different configurations for different "variants" (note
that the difference between a "release" and a "variant" is fairly fuzzy).

Snapshots cannot be used for these purposes because a snapshot does not
"evolve" ... it is a single immutable configuration (so you do use a
snapshot for a particular release, but if you are going to be producing
patches for that release, you'll need a stream, not just a snapshot).

Workspaces cannot be used for these purposes because workspaces are
updated by a single person, while these configurations are normally
maintained by a team (a "shared" configuration). Although if you have a
single user maintaining a release, a build, or a variant, then you
certainly could do so in just a workspace.

As for keeping them straight, you would do so by partitioning them into
the appropriate project and team areas. Having different "types" of
objects to manage slightly different flavors of "evolving
configurations" would be more confusing, especially when in the case of
"releases" and "variants", the distinction is a fuzzy one.

Cheers,
Geoff




On 7/25/2011 3:38 PM, knutson wrote:

Sorry to bring this up again, but I'm still a bit confused about best
practices.

I've seen the docs refer to using streams in a number of scenarios:

1. versioning of delivered code including major releases and service
releases
2. creating stream hierarchies for things such as intermediate build
integration levels
3. creating related variants of sets of files

The use of streams for different reasons makes it difficult to
understand best practices.

For example, use of streams for versioning purposes seems exactly what
snapshots were supposed to be used for. Using streams for
intermediate build integration levels seems like that is what
workspaces were for. Using streams for creating variant collections
(e.g. Product, instrumented variant of product, educational variant
of product) seems like the right idea, but if I need to keep streams
separated by version and variant, things get confused and if I add a
build integration hierarchy of streams to that, it's really confused.
So what are the best practices? If we are really supposed to keep
all these things separated by streams, what are the best practices
for creating and managing them?

Thanks,
Jim