ClearCase: Is it possible to cancel checkouts not made from your own view?

Question

Can the project manager force cancellation of checkouts of files/directories made in any view/stream/project? How?

Bregenz

Answer 1

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.

Underlie

Answer 2

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.

Dactylic

Answer 3

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.

Repast

I have amended my answer to make that clearer, as well as to propose a way to restore those checked out files. – Underlie

Answer 4

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.

Godson