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
Related
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)
I am getting below error while updating the view.
Problems were encountered while retrieving view synchronization and data.
Clearcase CM server error: Unable to access "vob name" : unknown error in vob
Clearcase CM server error: Error 2 config spec load rule problems encountered
How to troubleshoot that error message?
You need to access the logs (both locally or on the server) to know more.
It used to be cleartool getlog (ClearCase 7.x, even for CC 8.x)
cleartool: Error: Checkout is currently disabled for element "element_name".
Its config spec rule information is currently unavailable due to either an aborted update or an update in progress
That is similar to an older CC (7.0.x) described in this technote:
Possible cause for symptom 1:
If an update, rebase or deliver operation is not currently in progress for the view in question, the error can often be attributed to the view being out of sync with the stream.
Try:
cd /path/to/snapshot/view
cleartool setcs -stream
Possible cause for symptom 2:
Hijacked nocheckout means that the version hijacked in the view is no longer the version the config spec selects from the VOB.
Rename the hijacked file and update the view.
Check out the version from which the file was hijacked.
Copy the hijacked file over the checked-out version.
Merge from the current version to the checked-out version.
The version can now be checked in.
Possible cause for symptom 3:
Per the error message explanation noted above, the problem may be caused by an issue with the view's config spec or an aborted or incomplete view update.
Try:
cd /path/to/snapshot/view
cleartool setcs -current
(original answer)
It can be a right issue, as illustrated by this thread.
Check group permissions on user and on those two VOBs.
Do you rely on the CLEARCASE_PRIMARY_GROUP environment variable?
If so, check the value of the user performing the update.
Compare the rights of the vob with the ones for your current snapshot view that you are trying to update:
cd /path/to/snapshot/view
cleartool lsview -l -full -pro -cview
If the CLEARCASE_PRIMARY_GROUP is not set properly, it is easier to:
set it to the right group (ie the primary group of the vob, or one of the secondary groups)
delete and recreate your view.
(if you do not want to delete/recreate your view, you can fix_prot it)
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.
My friend who recently left our organisation also left his ClearCase view undeleted.
Now we wanted to delete it.
I was trying to delete but it did not allow. It said:
Unable to remove "\\hostname\viewsharefolder\Viewname.vws"
Operation not permitted
Can administrator only delete his views?
If I deleted the (.vws) folder associated with view, for ex: "Components_int.vws", will it be enough?
Yes you can (for any view, snapshot or dynamic, UCM or base ClearCase).
You also can remove it without ever accessing it. (So removing the view storage isn't enough, or even necessary)
If you still have access to the view storage:
cleartool rmview theViewToRemove
If there is any access/right issue when trying to remove said view:
cleartool lsview -l theViewToRemove # get its uuid
cleartool rmtag -view theViewToRemove
cleartool unregister -view -uuid uuid_of_viewToRemove
That second solution is very handy in that you don't need access to the view storage.
You simply remove reference to that view in the central registry of ClearCase (specifically the view_object and view_tag files of your ClearCase registry server)
Tamir Gefen mentions in the comment the IBM script rmview.pl, which is also mention in the SO question "Delete ClearCase Views Script".
A simpler script is in my answer of that same question: "muke_view.pl"
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.