On clearcase machine, Let say i have a file called xyz.c.
I have checked out the file using command
jco -nc xyz.c
now i did some changes and checked-in the file(not submitted yet) using below command
jci -nc xyz.c
I have now a new version created for the file xyz.c, which we can see by below command
jlog xyz.c
---------------------------------------------------------------------------
Date: 04-May-11.13:05:02 User: abc
Event: create version
Version: xyz.c##/main/1
Comment:
---------------------------------------------------------------------------
Date: 28-Apr-11.12:19:51 User: abc
Event: create version
Version: xyz.c##/main/0
Comment:
---------------------------------------------------------------------------
Date: 28-Apr-11.12:19:51 User: abc
Event: create branch
Version: io.c
Comment:
---------------------------------------------------------------------------
Let say i have again checked out for my coding purpose and checked in again
which created version 2.
My question is : if i am on version 2, How can i delete the version 2 so that i can get my version 1. Note : version 2 is checked in but not submitted yet.
If you have checked in version 2 and:
don't have set any label on it
don't have create new other version on it
you could do a cleartool rmver xyz.c##/main/2, but that is quite dangerous and not recommended.
A revert (as I wrote here) would be:
cleartool merge -graphical -to xyz.c -delete -version \main\2
Another (less complex) option would be to hijacking the content of xyz.c with version 1, that is just replace the local copy (you would need then to checkout and checkin in order to create a version 3.
See SO answer on cleartool get:
cleartool get –to xyz.c xyz.c##\main\2
Your question is not very clear in terms, whether you have already checked in version 2 or not. In case you have not checked in version 2, you have to uncheckout the file. If you have checked in the file, you will need a rollback
My question is : if i am on version 2,
How can i delete the version 2 so that
i can get my version 1.
I do not think you do not have to delete it as such, my interpretation is that you just want to see the older version 1 at some point after version 2 is created, is that right?
All versions of the content of the file (e.g. versions /main/0, /main/1 and /main/2) are stored in the VOB. However, when you work with clearcase you are not accessing the VOB directly, you are working with a view and all file access goes through the view server. The config specification will determine what versions of a file your view will select.
So if you specifically want to see version 1 of the file you can add
element xyz.c /main/1
to the config_spec before the rule that would otherwise select a version (use cleartool ls -l to check).
Also I notice you use commands jco, jci and jlog which is not the same as the standard clearcase commands cleartool co, cleartool ci and cleartool lshistory. So it seems like you are using some additional interface layer, there might be some issues with this.
You can also just bring up the version tree on the file graphically and right-click on the latest version and select delete.
Related
I want to find in which ClearCase label a specific string was added in code?
I am using base ClearCase.
I recommended before (8 years ago) to limit the scope of your search and use the exec clause of a cleartool find.
Example:
cleartool find -all -type f -user myLogin \
-version "lbtype(A_LABEL)" \
-exec ...
If you can do so in a dynamic view, you can then directly grep the content of CLEARCASE_XPN, the variable set by cleartool find for each version found.
It reference an extended pathname that (in a dynamic view) you can directly read and grep for your code)
You can do so for each label you can find in your Vob, from the oldest to the newest.
Z:myvob>ct lstype -kind lbtype -short
Z:myvob>ct find . -version "lbtype(A_LABEL)" -print
If you are looking for a specific change in a given source file, the cleartool annotate command will give you a good start. If you're familiar with GIT, this is the equivalent of "git blame."
Annotate works only if the element is one of the text file types (text_file, utf?_text_file, etc.) since those store delta information on a per version basis.
One caveat is that this will tell you what version the change came from, but if that version was created by a merge, you may have to backtrack the merge to find the original location of the change. ALMToolbox's "visual annotate" tool does that for you, if I recall correctly.
I'm using windows. I need to extract activity ids of check ins in ClearCase.
I can get the current one through cleartool describe and then parsing the response for the word 'Activity'.
I'm looking to get the activity ids of it's previous versions.
How can I do that?
You don't have to parse the output of cleartool describe, if you combine it with fmt_ccase.
That allows you to:
get the previous version of an existing version
cd /path/to/view
cleartool describe -fmt "%[version_predecessor]p" afile
get all activity id with that version involved:
cd /path/to/view
cleartool describe -fmt "%[activity]p" afile##/a/previous/version
(that is using the version-extended pathname ##/... returned by the first cleartool describe)
I want to check with a batch file if a certain element is already existent in Clearcase, or if I still have to add it.
How can I put this into a conditional statement?
Like:
if cleartool exists myFileName do myaction
else doOtherAction
You need to build a function which returns true or false depending on the element full name being part of the ClearCase view elements or not.
Then you can call that function from your if... else... statement.
Here are various commands that your function could use in order to determine if a file is a ClearCase element (meaning already added to source control) or not:
You can start by using the result of cleartool ls -l: if its output includes view-private object, it isn't added to source control yet.
cmd-context ls -long
version Makefile##\main\3 Rule: element * \main\LATEST
view private object bug.report
version cm_add.c##\main\0 Rule: element * \main\LATEST
derived object (unshared) hello##2007-03-24T11:32.418
version hello.h##\main\CHECKEDOUT from \main\2
Rule: element * CHECKEDOUT
Here 'bug.report' isn't added yet.
See more at "About view-private objects".
I already recommended that approach for a previous question using C#: "c# How to determine if a file is in ClearCase?".
Another approach is to use cleartool describe, which would trigger an error if the element described is a private one.
As mentioned in the technote "How to list view-private files in a view in Rational ClearCase", the command cleartool lsprivate works only in dynamic views, not in snapshot views.
For snapshot view, you can use: cleartool ls -r -view_only
Another approach is to use cleartool find, as in "Clearcase: How do I check if an element has a version on the trunk that was created after I branched off from the trunk?"
The following DOS batch file will add a file to ClearCase if it's not in there yet. Works in both dynamic and snapshot views.
#ECHO OFF
cleartool ls -l %1 | FIND "view private object"
IF %ERRORLEVEL% == 1 GOTO END
cleartool co -nc .
cleartool mkelem -nc -ci %1
cleartool ci -nc .
:END
You may want to add suitable comments instead of using the -nc switch.
I have somehow created a branch of a file in clearcase UCM that is not part of an activity. I have no idea how to reproduce this, but my stream is showing many files with this symptom. How can I find these files, remove them, and prevent it from happening again in the future?
Here is an example of one such file, names redacted to protect the innocent:
xxxxxxxxxxx.cpp##/main/xxx-integration/xxxxxx-xxxxxxxx/0 Rule: .../xxx-xxxxxxx/LATEST
A ct lsact -long | grep <filename> returns no results.
Update:
I used a find command to track down all the files that are on the branch given (and redacted) above, though I still do not understand the issue.
Per VonC's answer, where is what I ended up doing:
cleartool find . -type f -version "version(.../xxx/LATEST)&&version(.../xxx/0)" -print | tee ~/tmp/files2
I then read through the list of files generated to make sure they made sense, then I verified they were not attached to an activity and removed the versions:
cat ~/tmp/files2 | while read
do
if [ -z "$(ct describe -fmt "%[activity]p" $REPLY)" ]
then
ct rmbranch -f ${REPLY%/0}
fi
done
That can happen ig those file were checkout in a base ClearCase view, ie a non-UCM view, withg a simple config spec:
element * .../xxx-integration/LATEST -mkbranch xxxxxx-xxxxxxxx
You can use a find command similar to "How can I find all elements on a branch with version LATEST that has no label applied?".
The difference is: for each version found, you need to describe it in order to check if there is an activity attached to it or not (with a fmt_ccase):
cleartool describe -fmt "%[activity]p" "$CLEARCASE_XPN"
In a static view, how can I view an old version of a file?
Given an empty file (called empty in this example) I can subvert diff to show me the old version:
% cleartool diff -ser empty File##/main/28
This feels like a pretty ugly hack. Have I missed a more basic command? Is there a neater way to do this?
(I don't want to edit the config spec - that's pretty tedious, and I'm trying to look at a bunch of old versions.)
Clarification: I want to send the version of the file to stdout, so I can use it with the rest of Unix (grep, sed, and so on.) If you found this question because you're looking for a way to save a version of an element to a file, see Brian's answer.
I'm trying to look at a bunch of old versions
I am not sure if you are speaking about "a bunch of old versions" of one file, "a bunch of old versions" from several files.
To visualize several old versions of one file, the simplest mean is to display its version tree (ct lsvtree -graph File), and then select a version, right-click on it and 'Send To' an editor which accepts multiple files (like Notepad++). In a few click you will have a view of those old versions.
Note: you must have CC6.0 or 7.0.1 IFix01 (7.0.0 and 7.0.1 fail to 'sent to' a file with the following error message "Access to unnamed file was denied")
But to visualize several old versions of different files, I would recommend a dynamic view and editing the config spec of that view (and not the snapshot view you are currently working with), in order to quickly select all those old files (hopefully through a simple select rule like 'element * aLabel')
[From the comments:]
what's the idiomatic way to "cat" an earlier revision of a file?
The idiomatic way is through a dynamic view (that you configure with the exact same config spec than your existing snapshot view).
You can then browse (as in 'change directory to') the various extended paths of a file.
If you want to cat all versions of a branch of a file, you go in:
cd /view/MyView/vobs/myVobs/myPath/myFile##/main/[...]/maBranch
cat 1
cat 2
...
cat x
'1', '2', ... 'x' being the version 1, 2, ... x of your file within that branch.
For a snapshot view, the extended path is not accessible, so your "hack" is the way to go.
However, 2 remarks here:
to quickly display all previous revisions of a snapshot file in a given branch, you can type:
(one line version for copy-paste, Unix syntax:)
cleartool find addon.xml -ver 'brtype(aBranch) && !version(.../aBranch/LATEST) && ! version(.../aBranch/0)' -exec 'cleartool diff -ser empty "$CLEARCASE_XPN"'
(multi-line version for readability:)
cleartool find addon.xml -ver 'brtype(aBranch) &&
!version(.../aBranch/LATEST) &&
! version(.../aBranch/0)'
-exec 'cleartool diff -ser empty "$CLEARCASE_XPN"'
you can quickly have an output a little nicer with
(one line version for copy-paste, Unix syntax:)
cleartool find addon.xml -ver 'brtype(aBranch) && !version(.../aBranch/LATEST) && ! version(.../aBranch/0)' -exec 'cleartool diff -ser empty "$CLEARCASE_XPN"' | ccperl -nle '$a=$_; $b = $a; $b =~ s/^>+\s(?:file\s+\d+:\s+)?//g;print $b if $a =~/^>/'
(multi-line version for readability:)
cleartool find addon.xml -ver 'brtype(aBranch) &&
!version(.../aBranch/LATEST) &&
! version(.../aBranch/0)'
-exec 'cleartool diff -ser empty "$CLEARCASE_XPN"'
| ccperl -nle '$a=$_; $b = $a;
$b =~ s/^>+\s(?:file\s+\d+:\s+)?//g;
print $b if $a =~/^>/'
That way, the output is nicer.
The "cleartool get" command (man page) mentioned below by Brian don't do stdout:
The get command copies only file elements into a view.
On a UNIX or Linux system, copy /dev/hello_world/foo.c##/main/2 into the current directory.
cmd-context get –to foo.c.temp /dev/hello_world/foo.c##/main/2
On a Windows system, copy \dev\hello_world\foo.c##\main\2 into the C:\build directory.
cmd-context get –to C:\build\foo.c.temp \dev\hello_world\foo.c##\main\2
So maybe than, by piping the result to a cat (or type in windows), you can then do something with the output of said cat (type) command.
cmd-context get –to C:\build\foo.c.temp \dev\hello_world\foo.c##\main\2 | type C:\build\foo.c.temp
I know this is an old thread...but I couldn't let this thrashing go by unresolved....
Static views have a "ct get" command that does exactly what you are looking for.
cleartool get -to ~/foo File##/main/28
will save this version of the file in ~/foo.
[ Rewritten based on the first comment ]
All files in Clearcase, including versions, are available in the virtual directory structure. I don't have a lot of familiarity with static views, but I believe they still go through a virtual fs; they just get updated differently.
In that case, you can just do:
cat File##/main/28
It can get ugly if you also have to find the right version of a directory that contained that file element. We have a PERL script at work that uses this approach to analyze historical changes made to files, and we quickly ran out of command-line space on Windows to actually run the commands!
If File is a Clearcase element, and cat File works, and the view is set correctly, then try:
cat File##/main/28
(note: without the ct shell-- you shouldn't need this if you're already in the view.)
Try typing:
ct ls -l File
If it shows the file with an extended name similar to the above, then you should be able to cat the file using an extended name.
ct shell cat File##version