I had to deliver some code(a folder and some files inside) from an activity A from dev stream to int stream in ucm clearcase. before delivering I renamed the folder using another activity B and changed some files inside. Now, While delivering from dev to int, I cannot find A and B as undelivered work.
Please advise how to resolve. let me know if any other information is required.
The usual workaround would be to a non-UCM merge by activity, instead of an UCM deliver (which is not listing the expected activities), using cleartool findmerge.
See "How to merge changes from a specific UCM activity from one ClearCase stream to another"
cd /path/to/myView/myFolder
ct findmerge activity:B#\pvob -fcsets -c "deliver B" -merge -gmerge
See also "how to merge new folder from a sub branch to the main branch in clearcase?".
Related
I have a large number of files that I am trying to check in. This process needs to be done several times and is time and resource consuming. I am using the follow command to do this:
cleartool lsco -cvi -all -s | awk '{print "cleartool ci -c \"<Name of checkin>\" " <path to vob> | sh
This command does work, but it takes a very long time to run, as each file is checked in individually. Is it possible to checkin all files at once, or perhaps a faster method of checkin in the files individually. Is it possible to use the same concept, but for a mass checkout?
As I mentioned in "What are the basic clearcase concepts every developer should know?", ClearCase remains a file-by-file VCS, meaning each operation (checkout; checkin, merge) is done file by file.
clearfsimport remains one possible "bulk" operation (even though behind the scene, it will still checkout or mkelem for new files, copy, and checkin the files one by one)
That means you can use one view as source folder (clearfsimport will import any folder, ClearCase view or not), and a snapshot view with the same config spec as destination. See "ClearCase, use clearfsimport to perform brute force update" and "How can I use ClearCase to “add to source control …” recursively?".
With the -rmane option, it will even remove files which are no longer present in the source folder. See "Remove unused source code files".
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.
Hi I wanted to know if there is a way to do cleartool findmerge without creating .contrib files. Its a nuisance to have to remove them after merging.
It depends on your version of ClearCase and type of merge, as detailed in this technote:
The .contrib files are generally used to compare the file's previous contents with its new after-merge version; moreover, these files are view-private and can be removed.
There has been discussion around the ability to allow the end-user to disable/enable the .contrib creation; however, with UCM, since all checkouts involved in deliver or rebase activities are reserved, there is no chance of loss changes as a result of the merge.
The .contrib file, in regards to UCM, does not serve the same purpose, or hold the same significance as with base ClearCase.
Change request (RFE) RATLC00608266, was opened to improve the logic used for leaving .contrib files after a deliver or rebase operation. There is no danger for loss of data as a result of the .contrib not getting created.
This behavior has changed in ClearCase 7.0. where feature level 5 was introduced. When using the native client, contrib files are no longer generated when merges occur during deliver and rebase (the Rational ClearCase Remote Client continues to create and use these files)
So with CC7.x and for deliver/rebase types of merge (ie UCM merges), you can aboid the contrib files.
Not with CCRC or base ClearCase merges (which is used by a cleartool findmerge).
That is why that same technote details ways to remove multiple .contrib files in one command (like for /R %i IN (*.contrib) do del %i or del /s *.contrib* for Windows).
Can the project manager force cancellation of checkouts of files/directories made in any view/stream/project? How?
A ClearCase administrator can force all files of a given view to be considered as "not checked out" (which is the equivalent of canceling their checkout status), with cleartool rmview:
cleartool rmview -force -uuid (uuid_of_the_view) -vob \aVob
You can get the uuid by grepping the user in the output of:
cleartool descr -l vob:\aVob
See technote "Removing checked-out references of a view from a VOB".
It will work for any view (snapshot or dynamic views, base ClearCase or UCM views)
I would recommend limiting that command to a specific vob.
Anyway, that doesn't concern the Project manager unless he/she is also a ClearCase administrator (ie, he/she is in the same group than the ClearCase administrators group on Windows, or if he/she is root on Unix)
Regarding a cleartool unco (which you can attempt on a dynamic view only), keep in mind if will only work for:
Version creator
Element owner
VOB owner
root (UNIX and Linux)
Member of the ClearCase administrators group (ClearCase on Windows)
Local administrator of the ClearCase LT server host (ClearCase LT on Windows)
So, unless your project manager has created the Vob in which those checked out files are managed, he/she won't be able to undo checkout them.
As commented below, all checkout files of the associated vob \avob are no longer considered checked out (their status is reset, not their modified content, which is untouched).
In order to restore those checked out files, a user can:
for a snapshot view, list hijacked files (as in this technote)
for a dynamic view list eclipsed files (see technote on eclipsed files)
Each filename found can be piped to a clearcase checkout command.
So restoring the checked out files is fairly easy for a given view and vob.
You can't if it was checked out in a snapshot view. You may be able to if it was checked out in a dynamic view. You can use Find Checkouts to find checked out files and attempt to undo the checkouts from there.
Ideally, if it is a view that is accessible by someone with higher privilege, e.g. Clearcase administrator who possesses the VOB owner account, it is best to ask him to perform the checkin (if you are sure the file can be checked in) or a saving of the checkedout file followed by a "cleartool unco".
If it is not the case, the command
cleartool rmview -force -uuid (uuid_of_the_view) -vob <vob-tag-where-checkout-is>
should do the trick as mentionned previously by VonC.
However, be aware that this command cancel ALL the checkout in .
So if you have say :
\avob\file1.c
\avob\file2.c
Say both files are checkedout by the same view of the same user and you want to uncheckout only file1.c. The "cleartool rmview" command described above cancels ALL the checkout in the VOB. So file2.c will also be uncheckedout.
The good news is that the checkedout version will not be lost as they will stay locally in the absent user's view. He will be able to access them once he is back.
There is still another strategy how to handle other persons checkouts as an administrator. Gain access to the users snapshot view. If the computer is reachable, mount the snapshot location and use it as yours. In this case you may even checkin these checkouts as you see the changed files. Is the computer is unreachable, you can construct a new view.dat with the view UUID and populate your view with a cleartool update command for the critial files and directories. Changes in directory versions you will see and be able to checkin, file element changes are not reachable, so you have always to unco file versions.