Can anyone think of a quick, easy and fullproof way of listing only ClearCase Remote Client views from UNIX?
ct lsview obviously lists all the views, and you could search by looking at the Properties: section if you run a ct lsview -properties -full (gives you Properties: snapshot webview readwrite) then use a regex or something, but I'd be worried that someone calls their view 'webview' or something.
Has anyone got a foolproof way? Am I missing a flag or something? If only there was -fmt on lsview :S
A regex detecting 'webview readwrite' should be good enough.
But even simpler, our CCRC server runs into its own ClearCase region (for instance 'web').
So in our case: "listing only ClearCase Remote Client views from UNIX" ?
ct lsview -reg web
Related
Has anyone else run into this problem?
Have 1 ClearCase UCM stream. Created a view on my laptop, while on corporate campus.
Am now working remotely, create a 2nd view to same UCM stream on a VM in the corporate data center.
Try to rebase the 2nd view on the vm machine, ClearCase complains that it cannot contact albdServer on my laptop (Atria Location Broker service was not started).
Then it seems that ClearCase proceeds to rebase the first view on my laptop, not the 2nd view from where I asked for the rebase. Rebase is terribly slow, over 1/2 hour for seven files.
I know the first rule of ClearCase, but I am stuck with it ... any suggestions?
It depends on where the view storage is stored.
The easiest way to debug is to do a:
cd /path/to/second/view
cleartool lsview -l -full -pro -cview
That way, you can see where the view storage is, and (more importantly), if it is accessible (dir /path/to/view/storage.vws)
OP: By some wild chance does your domain use roaming user profiles? If you use the view creation wizard, the view creation options are stored in the local user registry so you don't have to reenter them.
If you have roaming user profiles, the local laptop's settings can/will "leak" to the VM. If you used the wizard for the first time on that VM, and didn't get prompted to set a storage location, that's the most likely reason.
I have Rational ClearCase v7.1.2.13
I need to delete certain checkouts from a view as these check-outs are reserved and the user has gone for a vacation.
Please help me.
The easiest to do is to "unregister" the user's checkouts:
cleartool descr -l vob:\myVob
# get the uuid of the user's view from the description of the vob
cleartool mount \myVob
cd m:\mynewView\myVob
cleartool rmview -force -uuid old_view_uuid
That will not modify anything in the user's views: the files are still being modified, but they won't be considered as checked out.
Instead, they will be "hijacked" (identified in snapshot view) or "eclipsed" (dynamic view).
The other option (put a reserved checkout as unreserved) is rarely possible, as it require access to the view as well as elevated privileges.
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).
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.