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.
Related
At our work, we are forced to use Clearcase UCM as our central repository (specifically for labelling/baselining, builds and code reviews), but our team wants to use Git as our real SCM system.
What we want to achieve is essentially a scraping service that takes the commits as they are pushed to our central Git repo, and push them on to a Clearcase VOB that is read-only as far as the development team is concerned, including important information such as the comment and the user name (exact date/time matching is not important, but getting the user correct is).
Our centralized Git server has been configured (using the excellent scm-manager) to accept Windows domain users and passwords, and our Clearcase servers use Windows domain accounts, but I am unsure how a scraper service would "impersonate" the correct user so this information is duplicated correctly in Clearcase.
I thought the chevent command might hold some promise, but that only gives access to the comment.
Is there any way to amend the details of a Clearcase event record once it is in the database, in particular the user-name? Or is there a better way to do this?
Again, we don't need a bi-directional bridge - all access to the Clearcase VOB as far as code commits is concerned would be through the scraper.
ClearCase is a file-by-file SCM, not a revision-based SCM.
(See "What are the basic ClearCase concepts every developer should know?" for a more detailed comparison between ClearCase and git)
That means, for each git commit, you need to:
clearfsimport into ClearCase any file included in the git commit.
Create a specific UCM activty for that import.
As a ClearCase admin, cleartool protect -chown on the activity: see "Why is the owner of the clearcase activity 'nobody'" (as well as a protect -chgrp, if the CLEARCASE_PRIMARY_GROUP environment variable wasn't correctly set at the time of the import).
Note that cleartool protect affects the entire "element" (file or directory), not just one version, so you cannot record the user id that way: the next import would overwrite that id with the id of the new committer whom content is imported.
Plus, you cannot changed the initial creator (see "Changing the name of the original creator of an element")
That means you should record that information (author and creator git id) in attribute:
see cleartool mkattr.
If I did want to accurately reflect the Git user as the "creator" of the new version of the file does that mean I would need a way to run clearfsimport as that user - impersonate them?
Yes: for each commit, you would need to clearfsimport "as" (runas in Windows, as mentioned in this thread) that use, in order for ClearCase to properly set the creator (if this is a new element) or the version author (if this is an update of an existing version).
The reason I didn't mention that possibility in the first place is that I don't have access to the credentials of another user, for me to switch to for each clearfsimport.
Other import tools (CVS, PCVS, RCS, SCCS, SSafe) simply:
ignore that creator/author information entirely.
add attributes of their own for tool-specific information (like the promotion group 'PVCS_GROUP', or RCS_REVISION.
Each time, you will find the limitation similar to:
clearexport_sccs ignores information in SCCS files that is not related to version-tree structure; this includes flags, ID keywords, user lists, and Modification Request numbers
most of our other systems that need the Clearcase history use the creator to reflect who made that change
That means your other systems can rely on the user ID version, except if it is the one used for the import (in which case they would consult the special attribute recording that data from the import)
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")
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.
I'm using only CCRC - I don't have ClearCase locally installed.
I use CCRC Version: 7.1.1 Build id: 7.1.1.03.00_2010C.D100803
I'm working with a mature user of ClearCase - they have hundreds of work streams in a complex child parent relationship tree. When I create a view or stream CCRC offers me a picture of this complex tree and the location of my view (or stream if I'm creating a stream).
However, once my local view is set up there appears to be no mechanism for checking the location of any views. CCRC menus which 'show ClearCase view configuration' only show the load rules (i.e. which VOB's I'm currently selecting).
Another post to Stack Overflow tells me that '.ccase_wvreg' lists the local file paths where local copies of the files are stored. But '.ccase_wvreg' doesn't show the logical name of the views.
So how does CCRC find a map the logical view names and their configuration?
Is there another file I can examine (or other work around?) which would show me the complete view configuration.
The only workaround I have today (other than being incredibly careful and keeping png images of the stream as I set it up) is to commence the process of creating a new view or stream and retrace my steps.
Its surprising that being able to confirm the location of a view is so difficult - given what happens if one mistakenly checks in or deliver to the wrong stream!!
The CLI (Command Line Interface) for CCRC might be able to provide more information, espcially regarding the config spec of your view, in which there should be mentioned the name of the associated Stream.
catcs [-username user-name][-ser/ver server-url][-pas/sword user-password]\
[-tag view-tag]
But check first in the properties of the view. It can also include that information.