I am currently using ClearCase over a remote network and it is painfully slow. It takes forever just to browse to the stream that I want to make a baseline of. Is there a quick, easy, and safe way to make a baseline from the cleartool interface of a specific stream?
Thanks,
Ian
The basic command, from cleartool man mkbl:
cleartool mkbl -view anUCMView aBaselineName
You need a view associated to your target Stream to apply the baseline.
I recommend using the -full option, in order to create a full baseline (rather than an incremental one by default).
Using a snapshot or a dynamic view for mkbl shouldn't make a difference, but I like working in a snapshot view, and setting my baselines in a dynamic view (in which I am sure I don't have any pending checkouts).
See:
"What is the difference between Full baseline and Incremental baseline in Clearcase UCM?".
"How to apply baseline only to a particular component?" if you need to limit it to one component.
Note: this is for a full ClearCase installation, not CCRC (ClearCase Remote Client).
Related
Is there a way to list all files modified since last deliver with clearcase ?
I'm using clearcase like this :
ct setview <myStreamName>
Then I work on files. But before deliver to integration stream, I want to check all modified file. Is there a way to list all file with pending changes and compare them with working revision ?
Edit :
<myStreamName> is a child stream with activities, created from integration stream.
Actually, that isn't quite right. The simplest way to see your pending changes is to run cleartool deliver -preview -long while set in your development view.
This will list all the undelivered activities and the versions on those activities, regardless of the component.
You can use diffbl, more or less, but you then have to delve into the mysteries of deliverbl baselines (created on every deliver operation listing the activities delivered in that deliver.) and use those baselines as a filter on the activities... This then gets more complicated because you can deliver the same activity multiple times if you delivered it, did more work on it, and then haven't delivered the additional work.
Just use deliver -preview -long...
setview will mask your current view, since you access your files directly through /vobs/yourVobs/.../yourfiles (as shown here).
If you are doing a deliver, that means you are using UCM and have set a baseline from your current view, on your current stream (that you are about to deliver to an integration stream).
If that is the case, do a diff between two baselines: (cleartool diffbl -ver baseline1#\apvob baseline2#\apvob)
the latest one of the integration stream.
the one you have set
For the first element, use a ct lsbl -comp C -stream S to get the latest baseline.
This assumes you are delivering one component.
I also mention deliver -preview in "ClearCase Inter project delivery": it needs an UCM view on the target UCM stream to operate.
See also "I need a list of all the component of a certain stream that still needs delivery to default".
The error message:
Error: Target stream "myStream" requires child development streams
to rebase to recommended baselines before performing deliver operation.
means the deliver policy "Require development stream to be based on the project's recommended baseline(s) prior to delivery)" is in place.
See "How to force rebase before each delivery?"
Try and change that policy, or, as enforced, rebase first.
Then do a deliver -preview.
Is there a ClearCase equivalent to hg shelve (or git stash for those of the other persuasion)? The closest I can think of is doing uncheckouts and saving keep files, but that means I'd have to hunt down the keep files afterwards, re-checkout the files and merge. I realize that ClearCase and Mercurial/Git have different philosophies behind them, but I'd be interested if there is any work in making ClearCase more "usable".
I listed a few for other version control tools, but none for ClearCase.
I explained, for ClearCase UCM, that a shelve command isn't easy to implement.
Instead of just saving the .keep files, you could save patches (unix diff between a .keep and its original version), since a patch can be re-applied later.
The other approach is to modify the config spec (easier when in a non-UCM view) in order to checking the currently modified versions in a new branch (see this config spec)
You can then decide to merge that branch later.
The philosophy is quite different.
In Clearcase, if you need to work on another branch/release, you usually have to use another Clearcase view. If you have Clearcase/UCM, it is even more true as you would use another view attached to another UCM stream. You would not be able to use the same view, whereas in Git, you would be able to stick to the same clone and perform a git stash, git checkout in order to start working on another release.
Now let's assume you need to work on another feature, for the same release. Under Clearcase/UCM, you would be able to create a new activity (cleartool mkact) and work on this new activity, using the same view. All the changes made will then be associated with this new activity. You will also be able to switch back to the previous activity using the command cleartool setact. The tricky part is if you need to deliver the activities separately. This will not necessarily possible as you might need to deliver both at the same time depending on the content of the changeset. This doc about determining dependent UCM activities is quite useful. If you need to move some changeset between activities, you can use the command cleartool chactivity with -fcset and -tcset options.
As a summary, with Clearcase UCM, if it is for different release, switch views and streams. If it is for the same release, play around with the UCM activities, knowing that it is less flexible than git stash.
Currently we use ClearCase UCM.. I am trying to evaluate possibility of using git in our project. I decided to create large repo with past three years changes from an integration stream. The pvob has 12 vobs under it. For purpose of evaluation(creating a worst case), I am putting all changes into single repository.
I want to create a base clearcase view and then adjust its spec for every baseline on the pvob. This will then synched to git repository.
Question in short: How can I create a base clearcase view given a pvob base line and keep changing its config spec to match every baseline?
(academic note : A picture of what I am trying to achieve.. )
(Approach discussed in ClearCase UCM: Is it possible to have a temporary view on any given baseline? is kind of work around in my case. I guess I can avoid the step of creating many temporary streams- not sure how!)
I am putting all changes into single repository.
This isn't the right granularity for a git repo.
Having done multiple ClearCase to Git migration, the right scale usually is one UCM component equals one Git repo.
How can I create a base clearcase view given a pvob base line and keep changing its config spec to match every baseline?
You don't have to create a base ClearCase view.
You can create a sub-stream to the Int stream, and manage the baselines you want to see there.
(cleartool rebase -bas xxx#\YourPVob)
You can then use an UCM view to that sub-stream as a source for your git import.
If that approach isn't possible (as I explained in my previous answer you mention, because for instance all baselines haven't been created in the same parent stream), then you can create a base ClearCase view and modify its config spec in order to select the baseline complete ids:
element * BaselineId1
element * BaselineId2
...
(A dynamic view here is more useful to tweak the config spec.
Once the config spec is set, you can update a snapshot view with the same config spec, and appropriate load rules, to use it as a source for your git import).
You need to make sure those baselines are:
full baselines (you can promote an incremental one to a full one)
referenced with their id (not their title, which is their visible name).
See also "Display Current Baseline with Cleartool":
cleartool describe -l baseline:aBaseline#\aPVob
cleartool descr -fmt "%[found_bls]CXp" stream:myStream#\myPVob
The second command would give you all baselines in a stream.
In both cases, you would see the baseline ids in addition of their names.
I have mention the ClearCase to Git migration aspect in :
"Migration from UCM ClearCase to GIT"
"How to integrate ClearCase development history into Git?"
"Save history from ClearCase to Git?"
"How to bridge git to ClearCase?"
"Sync GIT and ClearCase"
A good trick is to use:
git --git-dir=/path/to/git/repo/.git --work-tree=/path/to/ClearCase/view add .
That allows you to consider the ClearCase view as the working tree of your git repo (which is the destination of your import).
I generally don't try to import all baselines from all streams because it is too complex too soon (in order to get the sequence of those histories right).
I just get a few baselines from the main stream, import them and go from there (keeping the ClearCase referential as a read-only archive source for history research).
I am new to ClearCase . I have used rational synergy before.
We use ClearCase in our project for version control.
In my old project, I have used rational synergy, in which we used to create "tasks" for any modifications in the files.
I got to know that we have activities in ClearCase, which I want to use in our projects.
As of now, we just check-out the files and modify and checkin the changes.
But when I check my ClearCase --> Actions, I don't see the option ->WorkOn to start creating an activity.
We are currently using the following version of ClearCase:
Version: 7.0.1.D061004
Build id: BALTIC_MR1.D070516
Please tell me if i need to install anything else?
The "work on" would be (setact man page):
cd /path/to/your/ucm/view
cleartool setact anActivity#\yourPVob
To check on what activity you are currently working (lsact man page):
cd /path/to/your/ucm/view
cleartool lsact -cact
To check if a view is an UCM one or not:
cd /path/to/your/view
cleartool lsstream -cview
If there is a stream attached to your view, it is an UCM one. If not, it is a base ClearCase one (not this is separate for the nature of the view: dynamic or snapshot: you can have dynamic or snapshot view both for UCM or for base ClearCase).
another way is:
cleartool catcs
The config spec for an UCM view is automatically generated and quite more complex than the one for a base ClearCase view.
How Can I Revert to Earlier baseline? We have a UCM parallel development(multi-stream) project. Each developer have a snapshot view on Project's Integration stream.
Developers want to see earlier version of the application in their snapshot views so They can debug early version of application to find bugs.
When I want to change an existing snapshot views's foundition baselines, clearcase does not allow me. So How Can I do this?
Since you employ the term Baseline, I will assume you are using UCM.
On a stream, you can not revert backward a baseline.
One possibility is to make a parallel stream, with the desired baseline as foundation: this is the quickest way.
After changes on this new stream, you can make a new rebase to change the foundation baseline, but only if that new rebase is using a more recent baseline from the parent stream (not an older baseline)
For your specific need, I would recommand a non-UCM snapshot view with a simple rule
element * thePreviousBaseline
In order for the developer to have:
his/her current UCM view for development (always set on the LATEST of a branch associated to a stream)
a second snasphot view set to whatever baseline he/she needs.
That second snapshot view is completely not-related to the UCM project and takes advantage of the "full" nature of the baseline (do check that your baseline has been put as "full", not "incremental". If it is "incremental", simply change its type and upgrade it to full)
So, beside your current snapshot UCM view, you can create anywhere you want a non-snasphot view:
cleartool mkview -snap -tag mylogin_myComponentname_csl_snap -vws myPathToViewStorage myPathToRootView
cd myPathToRootView
cleartool edcs
[add the selection rule: element * myOlderBaseline]
[add the load rule at the end: 'load /myVob_Including_MyComponent]
[save, type 'yes']
That is fine for consultation/execution, but if you need to patch (that i is to write, check out and in some files), then I would recommend one UCM stream per baseline to be patched.
That way, the stream clearly represents the patch effort for a given baseline. There should not be too many of them, unless you put into production a new version of your application every five minutes... which is not advisable ;)
So to summarize:
the non-UCM snapshot view is unique and serve for a quick consultation/debug of one older baseline at a time.
for patches (source modification), you create a parallel stream properly named, with the correct foundation baseline, and then a UCM view on it. You can not only debug but also fix some bugs in an activity, the deliver that activity to the main Int stream if that bug need to be retro-fitted on an higher stream.
(note: all bugs do not always need to be delivered: they can be obsolete when compared with the current state of the development)
The way I have solved this problem is by making another Stream, a child Stream of the Integration Stream. The easiest way to create this Stream is to open ClearCase Project Explorer (not Rational ClearCase Explorer) and navigate to the Project and then the Stream in question. Right click on the Integration Stream and select "Create Child Stream..."
Click "Advanced Options" and select a baseline for each component. Do this by selecting the component and then selecting "Change..." and selecting the specific baseline you want to see. You probably want to select "Prompt me to create a View for this Stream." Select "OK".
Any developer can do this. You don't need to be a VOB owner or Project or Stream owner.
Well, it depends. Actually, the answer lies in setting up your config spec to point to the proper files. Your config spec tells your view which versions of elements to look at. But how you do write it depends on your project's approach to baselines. Did you apply a label to mark that baseline? If so, and if you only want to read and not checkout anything new, your config spec can be as simple as
element * <LABELNAME>
If you didn't use labels, you can also set up your config spec to show you files based on dates. It gets more complicated the more rules you need to add to constrain your element choices. If you have more specifics, I can try to elaborate on what rules you might need. Otherwise, I would read the manuals that come with ClearCase. If you view the Extended Help from ClearCase Explorer, and then do "Viewing Rational ClearCase Manuals On-Line" it should give you some links to the Command References. This is where I go whenever I need to modify my config spec in some new way.
Also, note that we only use dynamic views, so I don't know if snapshot views work differently.