I'm trying to use CCRC API in order to get pervious versions for a specific file and compare with the checkout file.
I know ClearCase can use get command. But how it works in CCRC API?
Does anybody have some example how to retrieve this version without changing the config spec?
Thanks,
Crispy
rcleartool has seen new commands with CC8.0.0.3 and CC8.0.4, but is still missing a 'get' command except for the very latest ClearTeam version (8.0.1: see the rcleartool list of commands).
I said as much in "How do I retreive previous or old version in CCRC 7.1.2".
With CCRC 8 (aka ClearTeam Explorer) supporting dynamic view, you can try and use version-extended path (or rcleartool get), but if you are talking about CCRC, you are likely to be with a ClearCase 7.2.x instead of 8.x.
A separate dedicated web view, with a config spec you can change remains for now your safest as in "available right now") option.
I'm writing code to compare my checkout file(some code is modified) with the latest version in clearcase. So I have to get the content of the previous version to compare with my checkout file.
That seems more a job for rcleartool diff -pred
-pre/decessor
Effectively converts the first pname argument into two names:
(1) the predecessor version of pname in the version tree;
(2) pname itself.
If pname specifies a checked-out version, the predecessor is the version from which it was checked out.
Related
I have checked out a file say "a.c" in my activity branch which is having version 3 from main line in clearcase and I did some changes to that file.
Now I want to do check in of that file on the main line but the latest version of that file in main line is now 7.
I want to put my changes to that file and hence it will create the version 8 of that file.
So how can I do check in so that I can merge my changes to the latest version of file. In other words I am having 3rd version of a file and I want to give my changes to the latest version of the file
Even before the delivery, a simple checking should trigger the merge, in an UCM dynamic or snapshot view.
If there is any conflict, the cleartool mergetool will popup then.
That is what this technote details:
To merge the latest version with your checkout
When you first check in (on Windows systems, issue the Check In command for) a non-latest version of an element, one of the following actions occur:
On the UNIX system and Linux, you see a message that the version you checked out is not the latest on the branch, and the checkin is prevented.
Enter a command in the following format:
cleartool merge -graphical -to file-or-directory-in-your-view \
file-or-directory-name##/main/LATEST
Using the -graphical option starts the Diff Merge or, if you merge XML versions, the XML Diff Merge tool.
The argument on -to specifies your checked out element.
The other argument is a version-extended pathname that specifies the latest version on the branch on which you are working (see the pathnames_ccase reference page for a complete description of syntax).
After the merge completes, save the results and check in the version by entering the cleartool checkin command from the view.
On Windows systems, a window opens and asks whether you want to merge the file now. If you choose to merge, an automatic merge is attempted. If your input is needed to complete the merge, the Diff Merge or XML Diff Merge tool starts. After the merge completes, you are prompted to check in the element.
It sounds like you are using a Base ClearCase branch to do your work. You have a few options in that case. You can, and should, check the work in on your private branch and then do your merge operation...
Options include, but aren't limited to:
Use the manual cleartool merge command.
Run "cleartool lsvtree -gra {file}" or use the "version tree" clearcase context menu item to bring up the version tree. Right click on the current version and you will get an option to merge to any other version...
If you're using view profiles and are done using the private branch, there is a "finish private branch" option in the ClearCase home base.
If you checked out unreserved on the same branch as has been updated, you can use the vtree browser or the command prompt to merge your changes forward and check them in.
Once you label file versions in a release, ideally you want to protect that code from inadvertant removal (please read everything before commenting). It is too easy to delete the code.
I know I can lock the label but the file versions attached to the label don't get automatically locked (you would have to create a perl script to do that?). You can lock an element but not an element version. Furthermore, once you lock an element, you can't check it out!!!!! STUPID. This stops future development! All I want to do is protect the code I developed (without copying it elsewhere for archive). A repository should protect the code you develop.
Of course, there is the protect command but that doesn't work in snapshot / web views.
Again, ideally you would want to lock all the element-versions in a release but still be able to continue development. The lack of this feature seems to be a gross oversight.
Any ideas? (if you have any perl scripts, please post)
It is too easy to delete the code.
It shouldn't be: the only way you will be removing that labelled version from a ClearCase VOB is through destructive commands like cleartool rmelem or cleartool rmver.
All you need to do is to have a (preop) trigger in place denying those commands for everybody (except a ClearCase admin).
Something along the lines of:
cleartool mktrtype -nc -all -ele -pre rmelem -nusers $nusers -exec \"$perl_cmd -e exit(1)\" NO_RMELEM\aim"
I would still recommend to lock the label anyway, in order to make sure it isn't moved to another version.
As in:
ct lock -nusers vobadm lbtype:FOO_LABEL#vob:/vobs/admin
But again, if rmver is denied, your (labelled) code is safe.
Actually, the OP was talking about rmname (the DEL) in ClearCase Explorer.
The fear is that if a file is deleted, and a label is moved, then one could ignore for a long time the deletion.
BUT a label should never be moved:
the label from a ClearCase UCM baseline is immutable (you cannot move it)
a label in base ClearCase should always be locked
I'm having a tough time with ClearCase. I'm working with a dynamic view.
Somehow, I got two files that are eclipsed. I compared the folder in my version (with the eclipsed files) with every version on my branch and every version on the main branch. The original files are nowhere to be found.
I searched for the files in Windows Explorer and found them in the lost+found directory (with a 32 character extension). This directory appears to be invisible because I can't see it in either Windows Explorer or ClearCase.
I opened a DOS window and ran cleartool. I removed the files (I had fun typing it all, plus the 32 character extension at the DOS prompt). I could not find a way to delete them from either Clearcase Home Base or ClearCase Explorer.
I thought this would solve my problem, since there are no more files with the same names anywhere on my computer.
I deleted the eclipsed files and created them again in Qt Creator. But when I opened ClearCase Explorer again, there they were - eclipsed! I cannot figure out where the evil twins are. I tried finding the eclipsed files by using cleartool. Nothing. I've tried many approaches I've found online - none work.
I tried stopping and starting the view. I deleted the eclipsed files again, closed Qt Creator and then opened Qt Creator again and recreated them. I tried many other things suggested - none made any difference.
If I'm eclipsing existing files, where are they? I'm starting to think that the real evil one here is the parent - ClearCase!
Eclipsed doesn't mean evil twins (the fact that you add multiple times a file does though).
When you add to source control a file, ClearCase will:
checkout the parent directory
access the file in order to create a temporary one (called 'afile.mkelem')
create the file in the ClearCase vob
check in the parent directory
I usually see repeated eclipsed file when ClearCase isn't able to access the content of a file, because another process prevents it.
Try adding those files after closing the Qt editor.
The OP Rob Moore mentions having solved the issue with:
I changed the view to main/LATEST, and the file showed up.
I went to the tree view of that file and noticed that I had a branch there with one version.
I compared my branch version with the main/LATEST and they were the same, so I deleted my branch and put my label on the main/LATEST version
So it is possible that, as soon as the element was added, it wasn't properly selected by the config spec (being a new version on a branch which wasn't part of the config spec), and its state reverted to "eclipsed".
Here is the situation,
I have installed and configured ClearCase Multisite,I did a mkreplica from SITEA (/dev) to SITEB (/dev). My import went successfully on SITEB. I happen to do few syncreplicas too on Both( SITEA and SITEB). I had both configured on Win2003.
Now the SITEB Operation system Win2003 happen with some OS related issues. Now I had recreate an Instance of win2003 and configured CC Multisite on it. Now since everything had been wiped out: I tried to do an mkreplica from SITEA /dev to SITEB /dev (A win2003 new instance)
But, to my surprise, it says SITEA has already exported a packed and exits.
I wanted to know if there is a way to wipe out old history of SITEA for /dev or do I have to rename SITEB to something different? I haven't tried renaming but before I do just need some views over it.
Amit
I no longer work in a clearcase environment, so this is from memory, but in order to get an exact overview of what is exported or not run the
multitool lsepoch
command and then try to figure out which epoch numbers that are not up to date (as far as I remember you can request numbers from the remote side with the -actual option). If you want SITEA to re-export some things it thinks it already is finished exporting, you have to change the epoch number for the replica you want to import into.
When you consider the mkreplica man page, it could be as simple as the destination directory (the directory for use by mkreplica as a temporary workspace) already existing.
You also have this technote which reports why the error, multitool: Error: Unable to create directory ".../VOB.vbs/s": File exists, occurs when attempting to import an IBM® Rational® ClearCase MultiSite® replica creation packet using multitool mkreplica -import.
It involves unregistering (unregister+rmtag) the vob created by the first mkreplica.
if you are 100% certain that SITEA is most up to date, and the old SITEB is no longer needed. You can do this...
At SITEA
cleartool chmaster -all -obsolete_replica replica:SITEB replica:SITEA
cleartool rmreplica replica:SITEB
Once the above is done, you are free to re-create SITEB from SITEA as per your usual practice.
I want to provide a URL such as "...mysite.com/my_installer.exe", but I want to be able to make it point to the latest version of my installer.
So if I create version 2 of the installer, the url will download "...my_installer_v2.exe".
I've looked at general URL redirection - 301 redirects, .htaccess etc - but they seem to be geared towards web pages, I'm not clear which, if any, would be appropriate, or if I should be approaching it differently.
If it's relevant, I'm on an apache server, using a PHP based CMS (Textpattern).
Must people have a copy that is "My_Installer_Latest.exe" which is replaced when a new version is released. So just point to that one and replace it when a new version comes.
You have the other versions as well "My_Installer_V2.exe", the only difference is the file that you replace each time a new version is uploaded. Very easy to do and fool proof
It migth be not the answer your looking for but when you write URL they need to have a meaning so the rigth thing to do, in my opinion, is your url should be something like mysite.com/last_version and then you can redirect that last_version to a php page (in your case) that is able to select the rigth download.
I mean I'm assuming you want to do it in a "smart way". You can always just replace the file everytime you update your software.
You could use Apache's mod_rewrite.
If you're using Apache, then perhaps you're also hosted on a unix system, and could simply use symbolic links: ln -fs my_installer_4496.exe my_installer.exe. Every upload, change the symbolic link to point to the new file.
On a unix system, you might start with "...mysite.com/my_installer_v1.exe" as a file and have served a link "...mysite.com/my_installer.exe" pointing to this version 1 file.
So if version 2 enters the stage or maybe a daily/nightly build with a timestamp as version,
you have the link updated on the filesystem and do not have to change the interface code in the CMS (html served to the client).
If there is a need to allow access via the web to older or unstable parallel versions, you can always refer to the real filename as href attribute in the a-element of the html.
In case you need it on the shell issue a command like ln -s my_installer_v1.exe my_installer.exe after having changed into the directory holding the file (the one being served as "...mysite.com/" in your example. The link in the html page would be something like my_installer.exe (latest version).
PS: ln -fs my_installer_v2.exe my_installer.exe would be the (f means force) next update in your scenario.