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
I am curious about an answer to Leonardo Marzo's question:
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" ??I must confess too, that my head hurts while trying to parse the statement: That [reverting a component to a previous baseline] would not be easy to do with a snapshot because the snapshot's baselines aren't in the stream.I realise that baseline creation is optional when you create a snapshot - although I'm not really sure why. However, presuming that baselines were created for a given snapshot (such as when a build runs) and that build snapshot is 'promoted' (which I believe is deprecated terminology), should the baselines not also be present/visible in the stream (or in the stream's components, to be semantic)? |
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" ??
|
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: |
On 2010/09/20 9:36, David Ward wrote:
If, after snapshot promotion, the baseline's are not in the stream, does 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. |
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 |
This has been educational .... I only have one more question about this.
You mentioned that Delivering baselines helps organize things for development. In the 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 |
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 |
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.
|
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 |
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 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 |
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.