The baselines for the snapshots are only in the snapshots. These didn't get delivered to the stream so they will not show up when showing baselines on the stream. The baselines serve as a marker for the build so that it can be recreated once your team has delivered more changes to stream.

For creating a snapshot of the early baselines, you can create a stream/workspace with them. You can specify the baseline for each component and then you may create a snapshot.

Using RTC 2.0.0.2

I had come to believe that I understood streams, snapshots and baselines
... but I now see that I'm conceptually missing something.

My team uses JBE builds to do all official building. Once a build is
tested, I look at the associated snapshot in the build repository, and I
do one thing .. I "promote" it to the stream. I don't create nor do I
deliver, any baseline's myself.

(actually once, very early in the project I did manually create a
baseline for all components and I delivered it. That's an exception however)

I don't manually create any baselines, and I've always assumed that the
snapshots created by the builds (the ones that I promote) have
baseline's associated with them.

However, when I do a "Show->Baselines" on any of the components in my
stream, I see one, and only one, baseline ... the baseline that I
manually created and delivered long before we were doing automated Jazz
builds. I see no other baseline's, even though the stream itself has
dozens of snapshots.

So, where are the baseline's for all the snapshot's that I've promoted
to the stream ?

A followup question ...

That early baseline that was 'delivered' to the stream has no snapshot
associated with it (I was new!) ... can I now go back and create a new
snapshot associated with that early baseline in each component ?

Not sure if I've explained myself well here .. hope so

Cheers
Dave

The snapshot is just a container for a set of baselines. The fact that promoting it changes where the snapshot is doesn't change the stream/workspace that it is in.

The two operations are definitely different from each other. You may create as many snapshots on a stream/workspace and it will not affect the configuration of the stream/workspace. This is the reason the baseline names are different. The snapshot was likely created from the JBE workspace, which accepted changes from the stream.

There is no requirement that you have to promote those snapshots to the stream. It may make it easier for others to find the snapshots though.

To be a bit more technical, streams, workspaces and snapshots are quite similar to each other. They all contain baselines of different components. The big difference is a snapshot doesn't change because it's preserving a configuration.

Ok, the baseline's created by the snapshot are in the snapshot ... but
the snapshot was promoted to the stream. Is "promoting" a snapshot
(containing baseline's) to a stream, not the same as delivering
baseline's to a stream ?

I guess I'm asking whether there is something functionally different
going on here (between promoting a snapshot/baseline compared with
delivering baselines), or whether we're just discussing how RTC displays
baselines in the two situations ?

Dave

A baseline is like a marker. In between the baselines are a bunch of change sets. So you can use a baseline to label the component and deliver it. For example, you can baseline a component in your workspace that has changes that should go to the integration stream. When you deliver the baseline, you also deliver the changes to stream. If you didn't have any changes then you would be delivering an empty baseline and the stream's component doesn't change other than having a new label.

When the team grows larger, it's useful to have baselines. Comparing components is easier because common baselines can be found. It makes finding the differences between components faster. It's also easier to discard a bunch of change sets with baselines. If a build fails and you want to discard all the changes, you can replace the component with the baseline of the last good build. Then you may accept some of the changes and work towards the state of the failed build to determine which of the changes caused the problem.

Ok, so what exactly is a "baseline" ? Does delivering a baseline to a
stream change the configuration of the stream ?

I had thought that delivering a baseline is just adding a "label" to the
current configuration.

Another way to think about this is that you really only deliver change
sets. A baseline is just a "marker" in the change set history,
representing "all the change sets that precede this point in the change
set history". That's why, when you deliver successfully to a stream,
although all of the change sets you delivered will be in the stream, the
only baselines that show up are those that are "pulled along" when the
"all the change sets that precede this point" condition still holds.

And "promote" (unlike "deliver") never has any effect on the
configuration of the target of the promote.

Cheers,
Geoff

On 9/8/2010 1:38 PM, tmok wrote:

A baseline is like a marker. In between the baselines are a bunch of
change sets. So you can use a baseline to label the component and
deliver it. For example, you can baseline a component in your
workspace that has changes that should go to the integration stream.
When you deliver the baseline, you also deliver the changes to
stream. If you didn't have any changes then you would be delivering
an empty baseline and the stream's component doesn't change other
than having a new label.

When the team grows larger, it's useful to have baselines. Comparing
components is easier because common baselines can be found. It makes
finding the differences between components faster. It's also easier
to discard a bunch of change sets with baselines. If a build fails
and you want to discard all the changes, you can replace the
component with the baseline of the last good build. Then you may
accept some of the changes and work towards the state of the failed
build to determine which of the changes caused the problem.

David Wardwrote:
Ok, so what exactly is a "baseline" ? Does delivering a
baseline to a
stream change the configuration of the stream ?

I had thought that delivering a baseline is just adding a
"label" to the
current configuration.

Great baselines discussion and I have a couple related questions. First is an assumption I want to confirm. Creating a snapshot in a workspace or stream appears to create baselines on all components. We can see those baselines in Source Control > Components, they show in Replace With on the component in a workspace. I had the impression from this discussion they were only visible in the workspace/stream they are associated.

Second question is a scaling one. We are moving customer to RTC who perform 70+ builds a day (developer and integration ). Each will create snapshots with some get promoted to streams. Are there issues with lots of snapshots (~12-15K/year we estimate) for performance? How about the dialogs that list snapshots/baselines? My observation as discussed above is all baselines appear in the lists.

Many thanks.

1. You may add those component baselines to another workspace. There is no restriction on visibility with baselines. For instance, you may create a stream/workspace from the snapshot even though it is associated with another stream/workspace.

2. There is a scope for searching for baselines in dialogs. If you're adding a component baseline to a workspace, you're going to see the baselines for all workspaces. You may filter the search down to a specific workspace. Although, I think it's more likely you're adding/replacing components from another stream/workspace/snapshot, which takes the latest baseline. For the replace, it will list a subset to choose from with a link to show more if you want to add something older.

Great baselines discussion and I have a couple related questions. First is an assumption I want to confirm. Creating a snapshot in a workspace or stream appears to create baselines on all components. We can see those baselines in Source Control > Components, they show in Replace With on the component in a workspace. I had the impression from this discussion they were only visible in the workspace/stream they are associated.

Second question is a scaling one. We are moving customer to RTC who perform 70+ builds a day (developer and integration ). Each will create snapshots with some get promoted to streams. Are there issues with lots of snapshots (~12-15K/year we estimate) for performance? How about the dialogs that list snapshots/baselines? My observation as discussed above is all baselines appear in the lists.

Many thanks.

There isn't a GUI performance problem, because the GUI's that list
snapshots/baselines always display a sub-set (starting with a few
dozen), with the ones with the most recent creation date being displayed
first.

So although there isn't a performance problem, there could be a
usability problem if you are interested in a baseline that was created a
while ago.

The current approach is to use the "promote snapshot" operation to
associate "important" snapshots with a particular stream or workspace.
So if you know ahead of time what snapshots are important, you can
promote that set to a particular stream/workspace. This will handle the
common case where you have a set of releases that people will want to
fall back to.

Alternatively, if you know the snapshot name-prefix conventions, you can
use the "Search -> Jazz Source Control -> Snapshots" operation to find
all snapshots whose name begin with a particular string.

But if you do want a snapshot/baseline that isn't one of those promoted
ones, and that isn't recent, and whose name prefix you don't know, then
it could be hard to track it down.

Work item 130615 requests "Baselines should have a predecessor/successor
graph display, including branching/merging, similar to the current file
history display". If you think this would be useful, you could add a
comment to that work item indicating your interest/support.

Cheers,
Geoff

On 9/9/2010 1:22 AM, harryk wrote:

.... We are moving customer to RTC who
perform 70+ builds a day (developer and integration ). Each will
create snapshots with some get promoted to streams. Are there
issues with lots of snapshots (~12-15K/year we estimate) for
performance? How about the dialogs that list snapshots/baselines?
My observation as discussed above is all baselines appear in the
lists.

Many thanks.

Why does the RTC documentation state:

A snapshot can be associated with one or more streams. A snapshot can be delivered and accepted in the same way as a baseline or change set

Is this correct ?