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.
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.
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
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")
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.