Workspace, streams, and components, oh my!
First, apologies for being UCM/stream rookie, which I think would help my understanding. But I have played a bit with the Jazz CM a bit and have some questions.
1) If I create a snapshot for my workspace in the Pending Changes view (ala 2.1 in Multi-Stream Development doc), I see new baselines for all the components in that Stream. Also, a 'Show Snapshot' on the on the workspace shows the shapshot. But a 'Show Snapshot' on the Stream (in Streams -> <streamname>) does not list it. So, are there separate snapshots for streams and for workspaces? If so, do both add a baseline to the components in that stream? And then, how do I snapshot a stream? So in general what is the best practice for using snapshots? Are they there to simply add a blanket baseline to all the contained components? 2) The 'Show History' for an artifact shows the work items that changed it, but no baselines/snapshots. I relate this view to a CC version tree. So, first I'd also like to see the metainformation - baselines, snapshots - marking version of this item. And then second I believe that data is as interesting in a linear form and am not sure a a table is the best representation. It is interesting to see how it changed over workitems and possibly phases/milestones/etc. Something closer to what I can create with a CC version tree with a decent branching strategy that follows my change process. 3) A single change can span multiple components (e.g., HTML/DB/Java). Is there a way to group all the change sets for a work items (which could consist of hierarchical work items) and deliver them together, forcing a deliver/accept that is all or nothing? Right now it seems like we accept change sets individually, which could cause errors or misunderstandings. Am I confused? Or is there a Jazz practice I am missing here? I beleive this is related to 2) above in that - I think - individual change sets are less interesting than the work item, or baseline, that groups them. Thanks in advance for straightening out my confusion. |
7 answers
harryk wrote:
First, apologies for being UCM/stream rookie, which I think would help Technically we could allow creating a snapshot of the stream, but since it's a shared resource, that is others are delivering to it actively, it could change underfoot at any time. If you really want to capture a good state of a stream it's less error prone to configure _your_ repository workspace with the configuration you want then take a snapshot. A snapshot is then remembered with the repository workspace and will have _exactly_ the configuration you want it to be. No one can modify it underfoot. Any repository workspace or stream can remember a snapshot, so you can from the snapshots view move a blessed snapshot to a stream. For our own selfhosting, the only snapshots we generally care about are those created in the builds. Everything is build driven, meaning that if I want to reproduce a build, I would open the build result and create a stream/repo workspace from the snapshot. So we don't actually create and associate snapshots with stream much. 2) The 'Show History' for an artifact shows the work items that You can see the baselines for a stream/repo workspace by selecting "Show Baselines" on the component or when viewing the history for a workspace select the "Show Baselines" button from the views toolbar. You can compare or replace at the baseline level, or see the change-sets within them. The file level history we show in Jazz is by default scoped to the current history. So we don't show all possible states of the file in other repository workspaces with whom you don't share the history. This means that if someone on your team is modifying the file in their repository workspace you won't see it until you accept that change-set. We find this to be the most common use of history, to see what you have and allows you to compare, replace, revert at that level. If you want to see everything, then switch to the all in repository mode using the History view toolbar. It's a typical CC user reaction to want a complete version tree. Our initial thought was to keep things simpler to start and provide a history view which supports the most common scenarios. If you are using a version tree to ask "is this version of the file in release X". Instead of showing the baselines as tags on the file history, you could pick the change-set which includes the file and see if it exists in the baseline you are looking for. I'd be really interested to hear user level scenarios that you miss from the version tree. 3) A single change can span multiple components (e.g., HTML/DB/Java). When you deliver or accept change-sets which span components the operation is atomic. If you want to deliver at a higher ganularity, you can group the change-sets into baselines and deliver the baselines. On the other end, you'll see incoming baselines in the Pending Change view and can simply accept them all without even looking at the change-sets within them. Someone can always accept change-sets individually if they want, but it can cause problems. The best practice is to accept the incoming baselines and not cherry pick from them. Thanks in advance for straightening out my confusion. It may of added to your confusion, but hopefully help a bit ;) Cheers, Jean-Michel |
I looked for a similar posting but don't this this specific case has been covered. I assume at some point best practices will be collected somewhere to cover such questions, but in the meantime, I hope someone can suggest a way to best handle this.
We have a large number (will grow to as large as 40 or so) of "products" that are developed independently. There are a handful of files used for building each of these, and they are identical for each product, at least at this point. The expectation is that these will change infrequently. I'm trying to figure out how to best organize components making the build files common. The source for each "product" will be contained in a a single component and then associated with a stream for development. At some point I'm sure we will likely want to spawn off separate streams for later release development, maintenance development, etc. The question is how to incorporate the "common" build files. My thought is that these should be placed in a separate component. And update of these perhaps restricted to one or a couple individuals. When changes are made to the common files, the change could be made in a separate dedicated stream and baselined. We may or may not want those changes picked up by the individual product. What would be the easiest way to control this? Add the common component to each "product" stream, specifying the desired baseline of the common component to be used. And if a change is made to the common component that we do desire to be adopted in the product stream, simple update the product stream and replace the common component baseline with the new desired baseline? And, how can we control update of the common component if it's included in several "product" streams? I hope this makes sense. Brian |
Geoffrey Clemm (30.1k●3●30●35)
| answered Aug 18 '09, 3:41 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Yes, add the common component to all the streams/workspaces that need it.
WRT how to control what configurations of that common component are used by different streams, I suggest creating a separate "common-component-stream" for each logical line of development of that common component. Then each product stream would have a "promotion" workspace, which has both the product stream and the "appropriate" common-component-stream as its flow targets. Someone would then periodically go into the promotion workspace, accept the latest from the common-component stream, and deliver to the product stream. Cheers, Geoff bgillan wrote: I looked for a similar posting but don't this this specific case has |
Geoffrey Clemm wrote:
Yes, add the common component to all the streams/workspaces that need it. Thanks Geoff. Is there any way to prevent someone who is a member of the team who owns the "product stream" from making changes to the common component and delivering them to the parent product stream. In other words, make the common component read-only in the product stream, so it's only updated in the common streams? Brian |
Geoffrey Clemm (30.1k●3●30●35)
| answered Aug 18 '09, 10:23 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Somebody has to actually do the update in the product stream, so that
person has to have permission to update that component in the product stream (RTC SCM does not allow the configuration of a component in one stream to be modified as a "side effect" of modifying the configuration of a component in another stream, because that would either: - overly constrain how that component can be modified in the other stream, or - bypass the modification rules of the one stream But I agree that you should be able to declare that "only the component configuration of this stream can be used to update the configuration of that component in this other stream". Unfortunately, you cannot declare that today, but this a work item (86817: "Restricting a stream so that it can be updated only with the configuration of one of its child streams") requesting this functionality. As always, please feel free to add comments/support to that workitem. Cheers, Geoff Brian Gillan wrote: Geoffrey Clemm wrote: |
Geoff, I don't completely follow your discussion regarding restricting a
stream... I was pointed to this article http://jazz.net/library/article/215#componentadvisor, but it seems like a very convoluted way to achieve what we want... to simply make access to a component read-only in a given stream. Seems like ClearCase had this capability with UCM projects, where when creating a project or stream (can't remember which) you could select that components could be modifiable or not. Regards, Brian |
Geoffrey Clemm (30.1k●3●30●35)
| answered Aug 27 '09, 5:00 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
A request to simplify this appears in workitem 90157: It should be much
simpler to declare "the following components are read only in this stream" Please feel free to add your comments/support to this work item. Cheers, Geoff Brian Gillan wrote: Geoff, I don't completely follow your discussion regarding restricting a |
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.