I am attempting to check in hundreds of new files in Base ClearCase. Due to network and server issues, I am wanting to write a batch script of cleartool commands to add each file to source control. All files will be checked in under a single ClearQuest task.
I have tried selecting all the files and adding all at once via the context menu, but after selecting the ClearQuest task association and choosing "apply to all", I am still having a dialog box pop up for every file, asking me to confirm the association.
I want to write a list of commands like:
cleartool mkelem -c "SCR ... / TASK ... - blah blah" filename.ext
However, I don't know how to associate the change with the TASK, and I don't see any documentation for doing this in Base CC/CQ.
First, don't write a script adding new files throug mkelem: if you can isolate those files in their own folder (or tree of folders) outside a view, then you can import them into a view (snapshot or dynamic) through clearfsimport.
clearfsimport is made for that, and will checkout the parent folder of the files to add, and do the required mkelem for each file for you.
See also "How can I use ClearCase to “add to source control …” recursively?"":
clearfsimport -preview -rec -nset c:\sourceDir\* m:\MyView\MyVob\MyDestinationDirectory
You will need first to use cleartool settask in order to set the ClearQuest task for the destination view used for this import.
See "How to configure base ClearCase to use the Change Management integration with ClearQuest".
As the OP Darthfett adds in the comments:
However, as I am using ClearCase 7.*, there is no settask command.
As a workaround, it looks like using set CQCC_AUTO_ASSOCIATE=<TASK ID> will work (see here)
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".
I recently started usage of clear case tools for maintenance of code in better way. But after some days my "Company" forgot to take licence from IBM as result I cannot CHECK-IN my code into clearcase. To continue my coding i created a separate folder in other drive and copied code solution in that folder. I and my colleague modified around "9865" files of solution within "45" working days. Now a "Company" borrowed a licence for me and I able to access code clear case tool successfully.
Problem is:
How to check in my "9865" files into clearcase in better way?
I tried:
Copied all solution into Snapshot view folder location. but, all
changed files are showing "hijack".
The best way is to use clearfsimport: that will automatically checkout, and import your 9865 in one command.
Make sure to update your snapshot view first, in order to restore its original content.
Then clearfsimport those files.
clearfsimport -preview -rec -nset /path/to/sourceDir\* </myview/VOB>
The clearfsimport command will detect the files added or modified, and do the checkouts for you.
If you are using an UCM view, set an activity first.
The source from where clearfsimport does that copy can be any regular folder.
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.
I created a view using cleartool command.
cleartool mkview -tag code-count-view -nsh $ccViewspath+$ccViewName
But as it is added as part of script while executing next time , i am facing issue says that view exists already
How to verify whether view name already exists or not?
A simple cleartool lsview yourViewTag is enough to check if a dynamic view exists.
Which is your case (your cleartool commands creates a dynamic view)
For a snapshot view, you would have the additional issue to find/check the root directory of said snapshot view, which isn't always easy.
That's a problem we've already faced in ClearEnv, our ClearCase add-on tool that automatically creates working environments by predefined templates, so I can share my insights.
My advice: do the following checks:
Check in ClearCase registry if the view tag is already exist
Check if target folder is already exist
You also have to do further checks if you want to create shortcut to ClearCase explorer and could be that there are more scenarios you have to deal with
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.