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.
Related
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.
I have created a symbolic link for folder1 to make it available in vob2\rootdir from vob1\rootdir.
And I labeled the whole directory folder1 recursively in vob1.
But when I modified the configspec of dynamic view to load folder1, it was loaded under vob1; But I couldn't see that folder in vob2\rootdir. Pls help.
First you don't modify a config spec to load anything in a dynamic view: you only modify selection rules, there is no load rules (as opposed to snapshot view).
If you were actually using a snapshot view (with a path different from M:\ or /views), then beware of symlink resolution issue like this one.
Finally, if your config spec doesn't select vob2/rootdir, or if it doesn't select the version which recorded the symlink, you wouldn't be able to see said symlink.
That means, labelling vob1/folder1 isn't enough: you need to make sure that:
/vob2 is labelled
/vobs2/rootdir is labelled as well
In other words, the parent folders of your final selection target (target being '/vobs/rootdir/folder1) must be selected.
Within 'Pending Changes' RTC source control is listing my target folder as an outgoing change. My project is maven based. I have not made any changes to the target folder.
When I compare the target folder with the stream I am flowing to I there are no differences displayed :
Is there some other criteria that is causing the 'Pending Changes' view to list my target folder & how can I determine what change is being recognized by RTC ?
When I try and undo the changeset within the target folder I receive the error :
The little + in the black arrow above the 'target' directory means RTC detects said directory as a new element to be delivered.
That means you must have checked in that directory with the rest of your changes.
Generally, target should be ignored (ie never considered to be checked-in in the first place).
In your case, you should:
remove that directory from your changeset (assuming you didn't already complete the changeset): try undo on the target directory within your changeset.
(That would actually trigger, for a newly created element, the error message
"Undoing this change would produce an orphan with no parent folder").
Right-click and select "ignore"
(don't select "Reverse" on the changeset itself: it would roll back all the changes currently checked-in)
add it to your .jazzignore: the ignore option will add or create a .jazzignore, in order to declare your directory in it.
Of edit your .jazzignore if you have already one, with a content like:
core.ignore.recursive= \
{target}
Note: with ClearCase, the issue is different, since ClearCase doesn't detected what is private from what is checked-out (and you don't check out with RTC).
You need to ask explicitly for all private files or all checked out files.
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.