Yesterday I received a new computer at work. My old computer had several Clearcase views (snapshots) containing a number of files that were stilled checked out. The process for building my new machine copied the directory containing my Clearcase view to my new machine.
My new machine's ClearCase now has no idea that those directories are ClearCase views and therefore that they contain checked out files that I'd like to keep.
How can I associate those directories to ClearCase so I get back to the state that they were in on my old machine (i.e. the directories are controlled by ClearCase and checked out files are recognized as such)?
Thanks,
Todd
The easiest way is to:
unregister and rmtag your previous view,
(because registering the same view on a new computer doesn't work well)
See "How to delete clearcase views created by other users?"
mkview a new view on your new computer,
See "Proper 'cleartool mkview' for ClearCase Snapshot view creation"
and clearfsimport -rmname your current modifications in that new view on your new computer.
(as in "Rollback via label in clearcase")
Related
I am not been able to change any parameters in clearcase GUI? Any suggestions how to fix it.
I want to give the view tag and stream name as I wanted but it is not allowing me to write or change anything in clearcase explorer.
A ClearCase Explorer is for the view, files and directories.
You cannot change the name of a view, through GUI.
You could follow the process describe in this IBM technote (rmtag, unregister, moving the view storage, register, mktag...).
But frankly, you would be better off creating a new one (with the same config spec, which means, for an UCM view, create a new UCM view referring to the same Stream)
A ClearCase Project Explorer is for all UCM metadata: pvobs, projects, streams, activity.
You cannot change an UCM name through the GUI (at least in 7.x, the ClearTeam 8.x interface could be more helpful).
But you can rename a stream easily enough through cleartool rename stream:aStream#\aPVob nameName.
However, I would then recommend to build a new view pointing on the new Stream (instead of resetting the config spec, with a cd /path/to/your/view; cleartool chstream --generate)
I would like to reload a view (which was created previously) instead of creating a whole new one.
Two scenarios:
1 - Hard drive crashes and the local view isn't there anymore.
2 - A new laptop is set up with ClearCase.
In either (or both) of these cases, can a view be restored on your local drive? Or does the view have to be removed and then create a new one? I would rather not have STREAM_2_int and STREAM_3_int if I can get away from that.
(Side question: If someone has a desktop and a laptop, can they use the same view on each, or is it only one for each computer?)
Yes, for a snapshot view, provided the ClearCase view storage (the .vws directory) isn't on the same workstation than the view itself.
The only file needed to make a directory a root directory of a (previously created) snapshot view is the hidden file view.dat.
See the IBM technote "Regenerate the view.dat file"
And the perl script (packaged within any ClearCase installation) used to restore that view.dat file is <ClearCase>\etc\utils\regen_view_dot_dat.pl -tag <view-tag-id> <view root directory path>.
Example:
C:\source>ccperl c:\Rational\ClearCase\etc\utils\regen_view_dot_dat.pl -tag aSnapViewName .
rgy_view_uuid: "d17190d381de4ce89757d5465eb41f2c".
creating ".\view.dat".
C:\source>type view.dat
ws_oid:00000000000000000000000000000000 view_uuid:d17190d381de4ce89757d5465eb41f2c
Again, that can only work if the view storage \\shared\path\to\aSnapViewName.vws is in a shared path accessible from the workstation or from the new laptop.
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.
We use both ClearCase UCM and base. One of the open questions we have is, how to find out where the loaded files of snapshot views are reside, by a given path of view storage directory?
e.g. We have a view located in C:\views\myview.vws
Sometimes the equivalent loaded files are in C:\views\myview directory, but sometimes not. I'm looking for a way to find where it is.
I tried to find it out by cleartool lsview -l and cleartool desc - does not help.
The Windows registry does not provide this answer as either (AFAIK).
I confirm there is not information where a snapshot view (UCM or not) actually resides.
You need to realize that by simply copying the .view.dat (hidden) file that you can see at the root directory of any of your snapshot view, you will make the destination directory (in which you copy the .view.dat file) the root of your snapshot view.
Copy it to three different directories, and you have the same snapshot view replicated three times!
Copy it to C:\Windows\System32, and that directory becomes a snapshot view root directory!
You best bet is to search for those .view.dat (or view.dat on Windows): those files contains the uid (unique id) of the view, allowing you to reconcile that with what you see within the view storage.
I see .copyarea.db files popping up in my ClearCase snapshot directories. I understand that deleting the file may cause some problems. How can I get rid of these files safely?
All CCWeb views have a storage stored at the CCRC server (which in turn communicates with the VOB server).
That differs from classic ClearCase views, where the view storage is either on the user's computer, or in a close View Storage server.
Since the clients using CCRC cannot always directly access that view storage (on the CCRC server), it needs "local" view storage, which are defined within the CCWeb view, with the .copyarea.dat and a .copyarea.db directories.
Since you are not the first to getting rid of those directories (.db and .dat), CCRC 7.1 now allows for .dat directory to be restaured, allowing then ClearCase to reassess the status of each file, keeping relevant information in the .db storage directory.
The first google result about .copyarea.db suggests that deleting those files will confuse ClearCase, causing it to think that your files are hijacked.
The .copyarea.db is removed by ClearCase after I add all the View Private files in a snapshot directory to source control. It makes sense--ClearCase needs the .copyarea.db file to avoid interpreting the copied files as hijacked, but checking them in removes that ambiguity, so ClearCase no longer needs .copyarea.db and deletes it.