Based on your answer to my other "baseline' question, I suppose that RTC
is definitely treating delivered baselines differently from baseline's
that are part of a promoted snapshot.

I guess I haven't been able to glean from the docs (and this forum) why
one should prefer to create baselines and then deliver them, rather than
create snapshots and then promote them.

If I've missed this in the docs then I apologize

Dave

Promoting a snapshot to a stream does not deliver the snapshot's baselines to the stream. Creating a baseline from your workspace and delivering it to stream is useful for delivering the state of one component to another workspace. A snapshot is used to preserve the state of a particular workspace configuration and does not affect the workspace or stream.

If you want to ensure a stream has the same set of changes as your workspace, you can baseline the component in your workspace and deliver it to stream. Creating a snapshot and promoting it to stream wouldn't achieve the same thing. The snapshot would belong to the stream but it does not replace the components. The stream would be in the same state as before you created the snapshot.

The key point is that the baseline in the snapshot does not live in the workspace where the snapshot resides. So in your example, the baselines in the snapshot are not the same baselines as the one in the stream. They may have completely different configurations.

Thanks for that

I think I've been working from the wrong set of assumptions regarding
baseline's and snapshot's.

Your remarks about "snapshot's replacing components" makes me pause. I
had assumed (incorrectly I think) that a baseline is a "label" on a
stream (like a CVS tag) and that a snapshot is just a collection of
baselines.

I can't find much material on best-practices for creating baselines and
delivering them, vs promoting snapshots. Is there any ?

On a new thread I'm going to ask whether one should prefer one over the
other.

Dave

Hi David,

I agree that the different semantics of baselines and snapshots can be
confusing.

The basic data model of the two is probably what you'd expect ... a
baseline is an immutable configuration of a component, and a snapshot is
a composite component, i.e. a set of baselines, each from a different
component. See work item 90294:

Replace "snapshots" with "composite baselines"

The way you create them is probably also what you'd expect ... you
create a baseline with the "new -> baseline" operation applied to a
component configuration in a stream or a workspace, and you create a
snapshot with a "new -> snapshot" operation applied to a stream or
workspace.

So far, so good. Objects are well defined, and consistent.

Now here's where (I think) it gets a bit confusing.

A baseline is like a version, and has a predecessor, but unlike a
version, it only has a single predecessor, so they don't capture when
two baselines are "merged" (those merge relations are lost). See work
item 130615:

Baseline merges should be captured in the stream/workspace history

With snapshots, they don't even have a predecessor relation. So there
is no way of recording or querying for the logical predecessors or
successors of a snapshot. See work item 130620:

Streams and workspaces should have a snapshot history, similar to
the way a component in a stream/workspace has a baseline history

Instead, snapshots just have a single stream/workspace they are
"associated" with, and you change that association with the "promote"
operation. But "associated with" doesn't mean "has had this
configuration", since you can "promote" a snapshot from the
stream/workspace it was created in to any other stream/workspace,
without changing the configuration of that other stream/workspace. So
that is really just a way of grouping snapshots, and doesn't necessarily
represent any semantic relationship between that stream/workspace and
that snapshot.

Cheers,
Geoff

On 9/8/2010 9:23 AM, David Ward wrote:

Thanks for that

I think I've been working from the wrong set of assumptions regarding
baseline's and snapshot's.

Your remarks about "snapshot's replacing components" makes me pause. I
had assumed (incorrectly I think) that a baseline is a "label" on a
stream (like a CVS tag) and that a snapshot is just a collection of
baselines.

I can't find much material on best-practices for creating baselines and
delivering them, vs promoting snapshots. Is there any ?

On a new thread I'm going to ask whether one should prefer one over the
other.

Dave

On 9/2/2010 4:37 PM, tmok wrote:
Promoting a snapshot to a stream does not deliver the snapshot's
baselines to the stream. Creating a baseline from your workspace and
delivering it to stream is useful for delivering the state of one
component to another workspace. A snapshot is used to preserve the
state of a particular workspace configuration and does not affect the
workspace or stream.

If you want to ensure a stream has the same set of changes as your
workspace, you can baseline the component in your workspace and
deliver it to stream. Creating a snapshot and promoting it to stream
wouldn't achieve the same thing. The snapshot would belong to the
stream but it does not replace the components. The stream would be in
the same state as before you created the snapshot.

The key point is that the baseline in the snapshot does not live in
the workspace where the snapshot resides. So in your example, the
baselines in the snapshot are not the same baselines as the one in
the stream. They may have completely different configurations.

David Wardwrote:
Based on your answer to my other "baseline' question, I suppose
that RTC
is definitely treating delivered baselines differently from
baseline's
that are part of a promoted snapshot.

I guess I haven't been able to glean from the docs (and this forum)
why
one should prefer to create baselines and then deliver them, rather
than
create snapshots and then promote them.

If I've missed this in the docs then I apologize

Dave


On 9/2/2010 9:53 AM, tmok wrote:
If there are changes after the last baseline on the component, a
baseline will be created for the snapshot. The snapshot is a set of
baselined components so it's possible that when creating the
snapshots baselines were created.

David Wardwrote:
In the RTC client, when I look at my stream, each component is
annotated
with a Baseline's ID and Name, like so

Component1 (23: GoodBaseline)
Component2 (5: GoodBaseline)
Component3 (7: GoodBaseline)

What baseline is being displayed here ? (it's not the only
baseline

that exists in the stream AFAIK)


Now, this stream contains lots of snapshots and if I open any one
of

them, the components are annotated differently ..i.e. there are
other
baseline's shown

Snapshot: MySnapshot

Component1 (44: BuildBaseline2)
Component2 (7: BuildBaseline2)
Component3 (9: BuildBaseline2)

Why is the stream/component annotated with a different baseline
than
any
of the snapshot components ?

Any help appreciated
Dave

Hi Geoff

Been away on a trip and just getting back to this ....

Thanks to you and Tim for taking the time to explain this.

I suppose the important question for me is : Am I using RTC snapshots
and baselines correctly . i.e. in the way that the designers intended.

My present needs are pretty simple ... (at least) once per iteration we
do a 'formal' build (using a JBE) that we 'release' into Systems Test.
I really just want to capture the state of 'all' the components that we
used to create the built product ... in CVS/SVN language that's a tag,
or label, on the repo. I translated that into 'promoted snapshots' for
RTC.

Does the Jazz team itself use snapshots to record 'important'
configurations of source ?

Dave