SCM Best-practice baseline and snapshots

Delivering baselines helps organize things for development. In the Jazz SCM team, we mark baselines with the date before delivering changes to integration. If we break something, we can revert the SCM component to the previous baseline.

That would not be easy to do with a snapshot because the snapshot's baselines aren't in the stream. I believe the JBE accepts changes into its workspace and creates a snapshot from it. The baselines that were created do not get delivered back to the stream. However, you can use the snapshot to know what exactly went into the build.

Promoting snapshots doesn't really do anything except move it. It doesn't really affect anything other than if you search for snapshots on the build workspace they won't appear there anymore. If you want quick access to the snapshot, you could also look at the build result. It should have a link to the snapshot. Although, build results get pruned so older snapshots would have to be searched on the build's workspace.

Promote it if you want to show that this was a significant or notable build. It would be easier than using baselines. Also, use baselines to group changes in the stream. In bigger teams, this becomes important when sub-teams have one or two components in a separate stream. It isolates changes and they can deliver baselines to an integration stream (this is where the baselines help organize things).

Most (perhaps all) development projects need to 'label' an important
configuration (say, when a product is released to users) so that
configuration can be referenced later.

We used to call these labels "tags".

To this end, my team has been promoting snapshots created by our JBE's.
It seemed natural and easy to do. We have never created baselines and
delivered them.

What are the considerations for choosing one (promoting snaphsots) over
the other (delivering baselines) ?

Is there some doc on this that I haven't seen or found ?

Any help appreciated
Dave


P.S. I can think one reason to prefer promoting snapshots ... when you
have lots of components (as we do), its seems easier. I'd have to
baseline each component separately and then deliver each baseline.

Ok thanks

The snapshots that I promote to the stream, are indeed significant,
because they represent an important product milestone. It's good to know
that I'm doing something correctly.

I must confess that I'm still intrigued by this

That would not be easy to do with a snapshot because the snapshot's
baselines aren't in the stream.

So where are the baseline's that are contained in the promoted snapshot
? Don't they also go 'with' the snapshot into the target stream ?

Dave


On 9/8/2010 2:22 PM, tmok wrote:

Delivering baselines helps organize things for development. In the
Jazz SCM team, we mark baselines with the date before delivering
changes to integration. If we break something, we can revert the SCM
component to the previous baseline.

That would not be easy to do with a snapshot because the snapshot's
baselines aren't in the stream. I believe the JBE accepts changes
into its workspace and creates a snapshot from it. The baselines that
were created do not get delivered back to the stream. However, you can
use the snapshot to know what exactly went into the build.

Promoting snapshots doesn't really do anything except move it. It
doesn't really affect anything other than if you search for snapshots
on the build workspace they won't appear there anymore. If you want
quick access to the snapshot, you could also look at the build
result. It should have a link to the snapshot. Although, build
results get pruned so older snapshots would have to be searched on
the build's workspace.

Promote it if you want to show that this was a significant or notable
build. It would be easier than using baselines. Also, use baselines
to group changes in the stream. In bigger teams, this becomes
important when sub-teams have one or two components in a separate
stream. It isolates changes and they can deliver baselines to an
integration stream (this is where the baselines help organize
things).

David Wardwrote:
Most (perhaps all) development projects need to 'label' an important

configuration (say, when a product is released to users) so that
configuration can be referenced later.

We used to call these labels "tags".

To this end, my team has been promoting snapshots created by our
JBE's.
It seemed natural and easy to do. We have never created baselines
and
delivered them.

What are the considerations for choosing one (promoting snaphsots)
over
the other (delivering baselines) ?

Is there some doc on this that I haven't seen or found ?

Any help appreciated
Dave


P.S. I can think one reason to prefer promoting snapshots ... when
you
have lots of components (as we do), its seems easier. I'd have to
baseline each component separately and then deliver each baseline.

One more thought ..

If, after snapshot promotion, the baseline's are not in the stream, does
that imply that the build workspace (where the baseline's and snapshot
were originally created) MUST be preserved ?


On 9/8/2010 2:22 PM, tmok wrote:

Delivering baselines helps organize things for development. In the
Jazz SCM team, we mark baselines with the date before delivering
changes to integration. If we break something, we can revert the SCM
component to the previous baseline.

That would not be easy to do with a snapshot because the snapshot's
baselines aren't in the stream. I believe the JBE accepts changes
into its workspace and creates a snapshot from it. The baselines that
were created do not get delivered back to the stream. However, you can
use the snapshot to know what exactly went into the build.

Promoting snapshots doesn't really do anything except move it. It
doesn't really affect anything other than if you search for snapshots
on the build workspace they won't appear there anymore. If you want
quick access to the snapshot, you could also look at the build
result. It should have a link to the snapshot. Although, build
results get pruned so older snapshots would have to be searched on
the build's workspace.

Promote it if you want to show that this was a significant or notable
build. It would be easier than using baselines. Also, use baselines
to group changes in the stream. In bigger teams, this becomes
important when sub-teams have one or two components in a separate
stream. It isolates changes and they can deliver baselines to an
integration stream (this is where the baselines help organize
things).

David Wardwrote:
Most (perhaps all) development projects need to 'label' an important

configuration (say, when a product is released to users) so that
configuration can be referenced later.

We used to call these labels "tags".

To this end, my team has been promoting snapshots created by our
JBE's.
It seemed natural and easy to do. We have never created baselines
and
delivered them.

What are the considerations for choosing one (promoting snaphsots)
over
the other (delivering baselines) ?

Is there some doc on this that I haven't seen or found ?

Any help appreciated
Dave


P.S. I can think one reason to prefer promoting snapshots ... when
you
have lots of components (as we do), its seems easier. I'd have to
baseline each component separately and then deliver each baseline.

A snapshot is its own container for the baselines so associating (aka promotion) the snapshot with a stream still preserves the snapshot. Deleting the build workspace would still preserve the snapshot. Think of a snapshot as an immutable stream/workspace.

Ok got it

Thanks

On 9/20/2010 2:22 PM, tmok wrote:

A snapshot is its own container for the baselines so associating (aka
promotion) the snapshot with a stream still preserves the snapshot.
Deleting the build workspace would still preserve the snapshot. Think
of a snapshot as an immutable stream/workspace.

This has been educational .... I only have one more question about this.

You mentioned that

Delivering baselines helps organize things for development. In the
Jazz SCM team, we mark baselines with the date before delivering
changes to integration. If we break something, we can revert the SCM
component to the previous baseline.

How exactly do you 'revert' a component to the previous baseline ?

i.e. can baseline's (and their associated changesets) be removed from a
stream ?

Cheers
Dave


On 9/8/2010 2:22 PM, tmok wrote:

Delivering baselines helps organize things for development. In the
Jazz SCM team, we mark baselines with the date before delivering
changes to integration. If we break something, we can revert the SCM
component to the previous baseline.

That would not be easy to do with a snapshot because the snapshot's
baselines aren't in the stream. I believe the JBE accepts changes
into its workspace and creates a snapshot from it. The baselines that
were created do not get delivered back to the stream. However, you can
use the snapshot to know what exactly went into the build.

Promoting snapshots doesn't really do anything except move it. It
doesn't really affect anything other than if you search for snapshots
on the build workspace they won't appear there anymore. If you want
quick access to the snapshot, you could also look at the build
result. It should have a link to the snapshot. Although, build
results get pruned so older snapshots would have to be searched on
the build's workspace.

Promote it if you want to show that this was a significant or notable
build. It would be easier than using baselines. Also, use baselines
to group changes in the stream. In bigger teams, this becomes
important when sub-teams have one or two components in a separate
stream. It isolates changes and they can deliver baselines to an
integration stream (this is where the baselines help organize
things).

David Wardwrote:
Most (perhaps all) development projects need to 'label' an important

configuration (say, when a product is released to users) so that
configuration can be referenced later.

We used to call these labels "tags".

To this end, my team has been promoting snapshots created by our
JBE's.
It seemed natural and easy to do. We have never created baselines
and
delivered them.

What are the considerations for choosing one (promoting snaphsots)
over
the other (delivering baselines) ?

Is there some doc on this that I haven't seen or found ?

Any help appreciated
Dave


P.S. I can think one reason to prefer promoting snapshots ... when
you
have lots of components (as we do), its seems easier. I'd have to
baseline each component separately and then deliver each baseline.

I think I answered my own question

To revert a component to previous baseline, you just choose "Replace
with ..." in the Pending Changes view.


On 9/8/2010 2:22 PM, tmok wrote:

Delivering baselines helps organize things for development. In the
Jazz SCM team, we mark baselines with the date before delivering
changes to integration. If we break something, we can revert the SCM
component to the previous baseline.

That would not be easy to do with a snapshot because the snapshot's
baselines aren't in the stream. I believe the JBE accepts changes
into its workspace and creates a snapshot from it. The baselines that
were created do not get delivered back to the stream. However, you can
use the snapshot to know what exactly went into the build.

Promoting snapshots doesn't really do anything except move it. It
doesn't really affect anything other than if you search for snapshots
on the build workspace they won't appear there anymore. If you want
quick access to the snapshot, you could also look at the build
result. It should have a link to the snapshot. Although, build
results get pruned so older snapshots would have to be searched on
the build's workspace.

Promote it if you want to show that this was a significant or notable
build. It would be easier than using baselines. Also, use baselines
to group changes in the stream. In bigger teams, this becomes
important when sub-teams have one or two components in a separate
stream. It isolates changes and they can deliver baselines to an
integration stream (this is where the baselines help organize
things).

David Wardwrote:
Most (perhaps all) development projects need to 'label' an important

configuration (say, when a product is released to users) so that
configuration can be referenced later.

We used to call these labels "tags".

To this end, my team has been promoting snapshots created by our
JBE's.
It seemed natural and easy to do. We have never created baselines
and
delivered them.

What are the considerations for choosing one (promoting snaphsots)
over
the other (delivering baselines) ?

Is there some doc on this that I haven't seen or found ?

Any help appreciated
Dave


P.S. I can think one reason to prefer promoting snapshots ... when
you
have lots of components (as we do), its seems easier. I'd have to
baseline each component separately and then deliver each baseline.

On 2010/09/20 9:36, David Ward wrote:

If, after snapshot promotion, the baseline's are not in the stream, does
that imply that the build workspace (where the baseline's and snapshot
were originally created) MUST be preserved ?

No, the build workspace does not need to be preserved. Once a baseline
is created, it exists forever in the repository, even if it is not part
of any existing repository workspace or stream.

If you create a change set in your repository workspace, and then you
discard the change set before delivering it anywhere, the change set is
no longer present in any workspace or stream. But it still exists in
the repository. And you can accept it into a workspace later if you
know how to find it (for example if it is attached to a work item).

Baseline are somewhat similar in this regard. Even if they aren't part
of any workspace or stream, you can still make use of them if you know
how to find them. The easiest way to find a baseline is probably
through a snapshot that contains it.

Thanks David

My question was based on a mis-understanding about where a snapshot's
baselines actually are. I now get it that they are contained within the
snapshot and that even if the snapshot is promoted to a stream, the
stream itself doesn't contain the baselines.

This discussion is almost entirely conceptual and centers on my mental
picture of a stream as a sequenced set of changes ... I had thought that
a promoted snapshot was marker on that sequence of changes ... when
actually it is an artifact associated with the stream, but not part of
its changeset sequence.

I hope that I now have the right picture in my head

Thanks

On 9/22/2010 1:30 AM, David Olsen wrote:

On 2010/09/20 9:36, David Ward wrote:
If, after snapshot promotion, the baseline's are not in the stream, does
that imply that the build workspace (where the baseline's and snapshot
were originally created) MUST be preserved ?

No, the build workspace does not need to be preserved. Once a baseline
is created, it exists forever in the repository, even if it is not part
of any existing repository workspace or stream.

If you create a change set in your repository workspace, and then you
discard the change set before delivering it anywhere, the change set is
no longer present in any workspace or stream. But it still exists in the
repository. And you can accept it into a workspace later if you know how
to find it (for example if it is attached to a work item).

Baseline are somewhat similar in this regard. Even if they aren't part
of any workspace or stream, you can still make use of them if you know
how to find them. The easiest way to find a baseline is probably through
a snapshot that contains it.

 Very interesting thread. I have one more question. So, which are the consequences of delivering a baseline from a workspace to a stream. You are only saying "hey baseline, now you should also be visible from the component's stream node, when I click on Component--> Show baselines" ??