Is there any way to update a CC snapshot view (after changing the config spec) with the newer config spec removing some files from the view that existed with the previous config spec?
Basically what happens is that after the update I have numerous .keep folders/files and I know upfront that I do not want to have these.
Right now I do a cleartool.exe update -force -overwrite 'path to snapshotview', but I was wondering whether there's an option to prevent creation of .keep artifacts?
Not to my knowledge:
You need to explicitly specify the -overwrite option for the cleartool update command to be sure no .keep will be generated (associated with -force as you mention in your question).
The only option you can unselect to avoid .keep file if for the undo-checkout (where you can specify you don't want backup file by default).
That doesn't apply to view updates though.
Related
I have a file in lost+found which is checkedout but I do not see any viewreference. How can i remove the file?
I'm Checking in windows system. When I do a version tree, I see a view that was created in some unix system. I'm not able to get the uuid of the same.
How can I delete such file?
For the checked out state, You should be able to get the view uuid in the same way as in the previous question "How do I delete check-outs from a particular view in clearcase?".
That lost+found folder is part of a vob and a cleartool describe -b vob:\Avob should list the uuid of the unix view.
But if you are not sure which uuid matches the actual name of the old view you see in the version tree, you can check for that name directly in the registry server.
There are different option:
cleartool rgy_check -views
But also, since I have access to the registry server, I can do a simple grep of the name in the var/rgy folder where view_tag is:
<user>#<server> /path/to/ClearCase/var/rgy
$ grep -i <view_name> view_*
view_object:-entry=view_object;-hostname=server;-local_path=path/to/<view_name>.vws;-owner=<name>;-view_uuid=e670fe8a.fb0540e5.83f4.7f:82:a6:s8:e1:1a;-attributes=sumview;
view_tag:-entry=view_tag;-tag=<view_name>;-title=<title_View>;-hostname=server;-global_path=\\server\views\path\to\<view_name>.vws;-region=<region>;-view_uuid=e670fe8a.fb0540e5.83f4.7f:82:a6:s8:e1:1a;
That way, from then name, you get back the uuid and can remove the checked out state from the vob.
Regarding the file itself (in lost+found), see technote "About the lost+found directory", that I mentioned in "How do I retrieve a file if I undid a folder checkout in ClearCase?".
There are two possible ways to remove an object from the root of the lost+found:
The object can be moved to a new location in the VOB using the cleartool mv command
The object can be permanently deleted from the VOB.
Be careful with the second option (which involves rmelem), especially in UCM (where that object could have in previous versions baseline labels attached to them)
My ci trigger works well as soon as I don't use clearfsimport. In the special case of clearfsimport. the ci trigger cannot find the file.
Here's the way I build the filename in my trigger:
my $filename = ( $ENV{'LOGNAME'} ? $ENV{'CLEARCASE_ROOT'} : '') . $ENV{'CLEARCASE_PN'};
For both case (cleartool ci and clearfsimport, the file name is a local path to the file i.e L:\VobName\Path\file.txt.
I don't know two things:
How the trigger can open the file if I give to it a 'local path' that cannot be resolved on the server-side?
Why it still works with cleartool ci but not with clearfsimport
EDIT
Actually it seems the concerned files are removed by some program or script before the call to the CI trigger. After the execution of clearfsimport the concerned files are back there. This result that the trigger cannot open the file because it's missing. Does it mean CI triggers cannot work with clearfsimport?
The clearfsimport (which I use here to import files), might work differently that a classic ci.
a checkin means: the file is here, checked out, and is checked in
a clearfsimport means: the file is not here yet, he is added (declared in the parent folder), and directly checked-in (the doc says "reads the specified file system source objects and places them in the target VOB"), then the parent folder is updated.
So the check-in might occur directly in the vob, and not rely on actual pathname (CLEARCASE_PN).
Maybe you could try $ENV{'CLEARCASE_XPN'} (the extended pathname), to see if you can access the file that way (except you might need a dynamic view to access the content referenced by an extended pathname).
Clearfsimport operates more or less like a "cleartool checkin -from" command.
So, as a result, you need to use the CLEARCASE_CI_FPN environment variable.
Something like this test (using Perl) should work:
$ccpn = $ENV{"CLEARCASE_PN"};
if (!(-e $ccpn))
{
$ccpn = $ENV{"CLEARCASE_CI_FPN"};
if (!(-e $ccpn))
{
printf("Cannot locate File being checked in!\n");
exit 1;
}
}
open( INFILE,"< $ccpn");
This may not be the most straightforward way to handle it, but imports act differently because the file is not yet actually in the ClearCase repository when the trigger fires.
I have a static view with some files checked out that I am working on. Someone else checks in a bunch of changes that I want to add to my view. So, I run update on my view. It turns out they changed a file I have checked out. Now my view is left only partially updated and may not even compile until I figure out which checked out file I have to manually merge.
I know I can reserve my checkouts, but that blocks other devs from checking in stuff they are done with.
According to: http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.cc_ref.doc/topics/ct_update.htm
update does not apply to files or directories that are checked out to the current view.
So, it seems it's working as the atria/rational/IBM folk want it to work. I don't understand why it works this way.
Is there any way to update my static view and also automatically merge changes into my checked out files?
Is there any way to update my static view and also automatically merge changes into my checked out files?
Not really, since a checked out file is a file being modified locally, and cleartool update tries very hard to not touch any local file.
Your checked out file is selected by the element * CHECKEDOUT selection rule, which means any update won't update it (it is already selecting the right version).
You need to check in those file (triggering the merge, similar to "To merge the latest version to a hijacked file"), and check them out again.
But that isn't always possible since it would make a work in progress visible (checked in) to other views in the same branch.
The only other solution is to compute a patch between the checked in version and your checked out file, and apply that patch cleartool lsco -all -s -cview | xargs cleartool diff -diff, with the difficulty to diff between your checked out version and the LATEST version.
Is it possible in clearcase to checkout a file for modification such that it is impossible to check it back in? I’m going to be hacking some files on a private branch, only some of which I want to ever check in. I want to eliminate the possibility of accidentally checking in unwanted changes. (I know we can write a trigger to check for magic keywords in the checkout comment; I'm look for something built-in to CC.)
"Hacking some files" is spelled in ClearCase lingo: hijacked files in a snapshot view.
All you have to do is to:
lock those files (except for the few developers you know are likely to checkout/checkin the files: cleartool lock -nusers userA,userB,... aFile)
create a snapshot view
change the read/write right (at the OS level, nothing to do with ClearCase here)
modify them directly (without checkout them first, hence the "hijacked" state)
The OP Kevin Little adds in the comment:
Alas, we only use dynamic views
Easy enough:
"Hacking some files" is also spelled in ClearCase lingo: eclipsed files in a dynamic view.
All you have to do is to:
lock those files (except for the few developers you know are likely to checkout/checkin the files: cleartool lock -nusers userA,userB,... aFile)
create a dynamic view
copy the files you need to modify as aFile.tmp
modify the config spec to not select them
copy them back to their original name (they became "eclipsed" as their private version override their official versioned counterpart)
remove the "none" selection rules from the config spec
modify them directly
To not select them, add to the config spec (ct edcs) before the other rules:
element /a/path/to/aFile1 -none
element /a/path/to/aFile2 -none
...
To restore them, all you have to do is move or remove those files.
They will be dynamically be replaced by their original and still versioned element.
I don't know about the administration. From a user standpoint, you could have 2 views. In one view, checkout the files you don't want to check in. In the other view (your view), check them out unreserved. Then, if you try to check them in, you'll get an error because they're checked out to the other view.
Good morning,
is there any way to exclude only one particular directory from a snapshot's load statement, e.g. I want to load a whole vob named 'PM_CT' except the \PM_CT\lost+found directory
... is there an elegant way to do it? And how would I generally exclude all lost+found directories across multiple loaded vobs?
Cheers and Thanks,
-Jörg
I would like to make an addition to the previously posted answer:
The lost+found directories
To exclude the lost+found directories across all VOBs you can modify the previously proposed selection rule to be more generic:
#Skip the lost+found directories
element .../lost+found -none
However, using the '-none' flag causes the Windows ClearCase client to list errors when updating a snapshot view:
Unable to load "lost+found": no version selected in configuration specification.
Unable to load "lost+found".
It also does not properly unload any previously loaded folders or files, so you may need to recreate your snapshot view (or unload/reload the VOB) with the new selection rule if you really want to clean out the lost+found directories...
Elegance
For excluding any normal folder, the "elegant way" would be to specifically load the /main/0 version of the folder:
#Exclude the contents of a directory
element /VOB_name/folder_path /main/0
This will cause the folder to be loaded as empty and will not produce an error. It will also properly unload any loaded files. It unfortunately does not work for the lost+found directory, because it is always listed as version /main/0.
element /PM_CT/lost+found -none
The "elegant" way consists of:
adding a selection rule (here "-none")
loading all PM_CT without aking any question (load /PM_CT), if your view is a snapshot one
Note: in a config spec, always use "/": it is easier, and Windows as well as Unix ClearCase views will be able to interpret it.
Caveats:
the previous solution is for one vob, I do not think you could use "wildcard" for multiple vobs
the '-none' option can cause a snapshot view to fail during a deliver or rebase (UCM merge): for that kind of operation, a dynamic view would be more suited. That is for CC 2003.06 and early 7.0. I think it works better with the latest CC7.1.0.2
Note: that selection rule can also be used for dynamic views, in order to mask some directory you would not want to see.