SCM Best-practice baseline and snapshots
![]()
Tom Frauenhofer (1.3k●5●84●35)
| asked Sep 08 '10, 9:33 a.m.
retagged Dec 16 '13, 4:01 p.m. by David Lafreniere (4.8k●7)
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. |
11 answers
![]()
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 |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.