To create a new dev stream from an existing stream, I first created a snapshot of the existing stream and from this snapshot I created a new prod stream.
(similar to a ClearCase UCM rebase of a baseline from a parent Stream to a child Stream)
All of the new stream components are the same as previous. So 'dev-stream' & 'prod-stream' have the same components (the components have the same name and point to same baseline).
Should a copy of the components not instead have been created with the new baseline ?
Here is a snapshot of how my component appears in RTC for both 'dev-stream' & 'prod-stream' :
The baseline should not contain the word "prod" as this is a dev stream.
The problem is circled in red in screenshot: How or why has the word 'prod' appeared in the component name ? Can 'prod' be removed from the name ?
The component must be the same when you add a snapshot to a new stream : same name and same baseline name. (very similar to a ClearCase UCM rebase, where you would find the same baseline name used as a foundation baseline for the sub-stream).
The idea behind a stream is to list what you need in order to work : this is called a configuration, as in "scm" (which can stand for "source configuration management", not just "source code management").
The fact that your new stream starts working with a baseline named with "prod" in it has no bearing on the kind of development you are about to do in said new stream.
It is just a "starting point" (like "foundation baselines" in ClearCase are). Again, no copy or rename involved here.
In your previous question, you mentioned having the current stream as 'dev-stream', but that has no influence on the name of the baselines already delivered in that first Stream (whatever its name is). Those baselines keep their name, and if you snapshot them and reuse that snapshot in a new stream, you will get the exact same baseline name.
But the name of the first baseline you are using as a starting point doesn't matter, as long as its content allows you to start a separate development effort, isolated in its own stream.
Any baseline you will create and deliver on said new stream will be displayed on it, and you won't see anymore that first baseline name.
Related
On my project I have some files that are generated automatically, so you'd normally don't put those in Source Control.
But since this process takes a long time and they change quite periodically, I'd rather keep them in Clear Case database to not impose this process to every one that desires to compile the source that isn't directly related to these files.
So, is there a way that I could add files on ClearCase UCM without creating a version tree?
More directly, I'd like to know if there a way to only one version per branch. As if when delivering this file to the main branch, it would delete the old version an replace it by the new one.
I know that this is a bit unorthodox, but I ask this because I'm not interested by the generated files history and I'd like to save space in the server.
So, is there a way that I could add files on ClearCase UCM without creating a version tree?
No.
Unless those files are radically different from one generation to the next, (or are huge binary), ClearCase would only record the delta, which wouldn't consume too much space.
One trick would be to rename the stream in which the import of the newly generated source is done, and create a new stream, in order to not have a huge version tree over time.
In serena dimensions, there are two parallel streams (Stream A and Stream B) from the same ancestor. I require to merge few modified files from Stream A to Stream B. Can someone guide as how this can be done.
None tool provides "automatic merging".
Suppose you have stream A and stream B, same item in different revisions: X 1.0 - production, X 1.1 - Stream A, X 1.2 stream B
First you must choose wich stream will get the "final merged" revision. You can use a third stream, just for all merges, regression tests and action to production.
Usualy you create a "third" version, (ex: X 1.3 if you choose merge based on production), or use a existent stream revision (ex: X.1.1.1, if you chose merge on existent revision 1.1 on stream A).
Use "compare" tool to check differences and proceed merging.
It can also be done locally, by having both streams updated each in its own folder (I assume you have them both as this). Locally merge your changes from Origin to Destination stream (can be all or just the selected files). Make sure that nothing was broken on the Destination stream and make a deliver or check in of the Destination stream.
A good practices is to have all items written, completed or baselined in your Origin stream, whichever makes more sense in your project, prior the merging of the streams, and then as a double check you can Get your Destination stream from the server into a different path and verify that all the changes are merged and nothing was broken. Also action the items as written, completed or baselined in the Destination stream once this final check was successful.
When creating a new Snapshot what difference does checking "Create new baselines" make ?
If this is unchecked, a snapshot is created and all components in the snapshot are backed up and so created baselines ?
If this is checked then new baselines are created but they also seem to be created when "Create new baselines" is checked.
As per this thread
A snapshot is just a set of baselines (each baseline from a different component). It's what ClearCase would call a "composite baseline".
You can snapshot the state of either a workspace or a stream, whichever you prefer. That will automatically create baselines when needed, i.e., when the current configuration of a component in that workspace/stream is not currently captured in a baseline
So, as mentioned in this thread
When I create a new snapshot, it only create new baselines in changed components, not in components have no changes.
I suspect checking in "Create new baselines" will force the creation of baselines for all components, including the ones which were already at baseline.
That enforces consistency in the name of the baselines included in the snapshot.
Update Jan. 2018, 3+ years later: Dmitry Grigoryev mentions in the comments:
the label on that checkbox is much more clear in newer releases now
I have already delivered 3 changesets for given work item. Anyway I believe that it should be one changeset only.
How can I merge these changesets into one changeset?
Re: "I believe that it should be one changeset only". It isn't necessary, but I understand the desire to have one change set encapsulating all the work. It makes it easier to deliver from stream to stream, resolve conflicts and avoid gaps.
As VonC said, you can't technically merge the change sets, however, you can create a new change set with equal changes. It's a bit of work, and they'd all have to be in the same component. Change sets cannot span components. Also, if there are gaps between the change sets, you'll have some merging to do. Here are the general steps.
Sync up with your repository workspace's flow target, by accepting all incoming changes.
Discard the three completed change sets from your repository workspace. The next step is the trick.
In the Pending Changes view select the component and choose the context menu action to "Replace in ", where is your flow target. That will take the configuration of the component in your repository workspace, only missing the three change sets, and replace it in the flow target stream. Now you've "undelivered" the three change sets.
Accept the three change sets back into your repository workspace. They should now be the only outgoing change sets in the component, just as if you hadn't delivered.
Select the three change sets you want to merge and create a patch from them.
Remove the change sets from the work item.
Discard the change sets.
Apply the patch back to your sandbox.
Check the changes into one new change set.
Associate the new change set with the work item.
Deliver the new change set. Done.
As you can see, it's not a trivial task, and so you likely won't do it that often, unless somehow your team process requires you to do so.
If those change sets are already delivered to the stream, you can't.
If by "deliver", you mean "change set associated to a work item, but not yet delivered to the stream, then you can move files and directories from two of those change sets to the third, and then "discard" those two (now empty) change sets.
That means those change sets aren't "completed" (they haven't yet a green tick as an overlow on their triangle-shaped icon).
A change set gets completed when it is part of a baseline, or delivered to a stream.
I am wondering about 'deliverbl', how important are they for historical purposes or during development? All I know is they are created during delivery and includes activies.
If i am exporting major baselines from Clearcase to different SCM, should I consider 'deliverbl' as major baseline?
There are representing merges (from a child stream to another stream), so:
they should be considered, as they show the code "merged" (with potential conflicts resolved)
but you might have more trouble to export the merge hyperlink which shows the source of the merge
I like to export those baselines because their naming convention shows the stream destination name, as well as the date of the deliver, so you are left with clues about a merge between two branches.
However, their are unlabelled, so you might:
either need to convert those to a full baseline (cleartool chbl -full)
or decide to not bother with them and leave those out of your export.