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.
Related
We have a current set up of VOB such that source code and documents reside in the same VOB.
To reduce the VOB download time we now want to move the documents to a new VOB, so that only the code part remain in the old VOB.
Since there are lot of folders and files, its not possible to manually relocate each file/folder.
To do this, we need to write a script which will detect file types by their extension and move file types such as .doc,.pdf, .txt to the new VOB.
VOB server is Windows Windows 2008 R2 Enterprise edition.
I'm a novice!
Can someone help me out with the script?
Thanks
Nush
The process would involve cleartool relocate: see "Relocating elements to another VOB".
The best practice is to:
group all the right elements you want to relocate in one folder (cleartool move)
remocate that folder
It is best if what you want to split is cleanly group is one folder structure.
Note that relocate wouldn't work if you are using ClearCase UCM though.
See this article:
The reason for this restriction is immutable baselines: if an element has ever been in a baseline, it can never be moved to another place; the baseline needs to know where to look for it. So a UCM element really can't be relocated.
For reasons unknown, a folder was checked out to me in ClearCase. A coworker was working on a word document stored in that folder. I undid the checkout on the top level folder. Her document disappeared and she doesn't have a local copy. Have I totally screwed her over here? Is there any way we can get it back? Is it stored somewhere on the server and we just can't see it with the standard GUI interface? I was under the impression that you couldn't add to a folder if someone had it checked out.
If it is a dynamic view, the only place it can still be is in the view storage.
But, dynamic or snapshot, first check the \yourVob\lost+found folder: it is for any files:
added to source control
with no parent folder referencing it (which is exactly what you have done by undo-checkouting said parent folder of the work document).
See "About the lost+found directory" for more on that special folder.
If you find it there (with an "extended name"), then see "To move an element from the lost+found directory" in order to restore the file.
My project uses clearcase 8. we have around 10 dynamic views ( streams ). Each dyanamic view contains 5 VOBs.
After importing these dynamic views in windows clearcase explorer, all the 50 VOBs are appearing under each and every dynamic view ( though majority of the irrelevant VOBs contains just lost+found directory under it).
Once I have manually unmounted all of the irrelevant VOBs from the corresponding dynamic views but after a restart of my PC all the VOBs are appearing again every where.
I don’t want to view all the 50 VOBs in each dynamic view.
Is there a solution for this issue ?
PS: - I am not a clearcase admin / expert.
Please suggest.
Firstly, you can cleartool umount all vobs with
cleartool umount -all
Secondly, you can mount them without making them persistent:
cleartool mount \aVob
Through the GUI, they are generally mounted as "persistent", like if you did:
cleartool mount -persistent \aVob
That means they are recorded in the Windows registry, in oprder to be mounted again automatically at the next Windows session.
If you mount them through a script, without the -persistent option, you won't have that problem.
Finally, know that if one of your dynamic view need a vob, then you need to mount it (obviously).
But that same vob will then be visible on all your dynamic views (it will be mounted at least, even if no version in it is selected by the other views config spec).
To resolve that, you can add in another dynamic view which shouldn't see a particual vob:
element /aVob/... -none
(you can use '/' and not '\' in a config spec, even in Windows)
That will make that vob invisible for that dynamic view, while still being mounted and available for the first dynamic view which needs it.
you can create a bat file and use it to mount a list of VOB's using
cleartool mount \vobname
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.
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.