Background
In clearcase, I have a dev version tree for a file that looks like this:
(1)
|
(2)
|
(3)
When I run a certain program, it hangs up on an error that is in version (1) of the file. It will not look at other versions because my program is tied to a certain label. Therefore, I want to make an unreserved checkout of version (1) and fix the error.
Problem
When I run the command ct co -unreserved -nmaster -nc filename, it checks out the file in version 3 not version 1.
Question
How do I checkout version (1) of the file and make changes in that version?
You can checkout a version which is not selected by the config spec of your view, using cleartool checkout
Check out an old version of the file hello.h, using an extended path name to indicate the version. (Before you check in your revised version, you must perform a merge.)
cleartoolt checkout -un -nm -c "attempt fix of old bug" -version hello.h##\main\1
With -nmaster, checks out the branch even if the current replica does not master the branch. Do not use this option if you cannot merge versions of the element.
It would work for files (not directories) in dynamic or snapshot view.
Related
My eclipse suddenly shut down, and after that for a particular file, there are two files present:
the main file and
a .checkedout version of it.
Now the main file is not checkedout out from my machine, still if anyone else tries to check out the file: it shows it is checked out already.
I have seen from Clearcase explorer too, it is the same there.
Any solution for this?
It depends on the version of ClearCase (client and server, including their OS), and of the type of ClearCase view you are using (snapshot, dynamic, web view)
But in general, if a file is checked out and should not be, you can delete any checked out status associated to your view.
However, please note it will cancel all your checked out files done in this particular view (for that particular Vob), so make sure it won't impact your current work in progress (save it first elsewhere to be safe).
cleartool descr -l vob:\myVob
# get the uuid of the user's view from the description of the vob
cleartool mount \myVob
cd m:\mynewView\myVob
cleartool rmview -force -uuid old_view_uuid
Note: you can also get your view UUID with
cd path/to/my/view
cleartool lsview -l -full -pro -cview
That way, nobody else will see any of your previously checked out file as "checked out".
Note that a .checkedout file is typically the result of a failed checkout for permission issue.
Example:
Unable to rename "M:\myView\myVob\path\to\afile.png" to "M:\myView\myVob\path\to\afile.png.keep": Permission denied.
Checked out version, but could not copy data to "M:\myView\myVob\path\to\afile.png" in view: File exists.
Correct the condition, then uncheckout and re-checkout the element.
Copied checked-out version data to "M:\myView\myVob\path\to\afile.png.checkedout".
Checked out "M:\myView\myVob\path\to\afile.png" from version "\main\myStream\0".
Attached activity:
activity:deliver.stream_myStream.20120426.115512#\myPVob
One says an hijacked file is a file where the "Read Only" flag has been removed.
I tried to remove the "Read Only" flag (Windows) and ClearCase does not recognize it as hijacked. Then I tried to touch the file using Cygwin without actually changing any mode flags. This time ClearCase warns me, we've got hijacked!
It seems ClearCase only look at the timestamp of files not their content and not their read-only flags. This mechanism has a very bad side effects when working in parallel with git. For example, if I do this:
git checkout bar
git checkout master
It would be the same as:
touch foo
Thus, ClearCase will think foo was hijacked which is not the case. For huge projects, this would be very dramatic and unfortunately I always use git to quickly switch to back and forth in my snapshot view.
What would be a good solution in my case?
EDIT
A much more dangerous example would this one:
stat -c 'touch --no-create -d "%y" "%n"' foo > restore_timestamp
echo "ClearCase will not see this" >> foo
source restore_timestamp
rm restore_timestamp
When I work in parallel between ClearCase and Git, I don't touch to the git repo within ClearCase: I clone it elsewhere and work from there.
Actually, I don't create a git repo in the ClearCase view directly: I create it outside, adding in it all the file from the ClearCase view (using just for the initial add: git add --work-tree=/path/to/CC/view)
When it is time to synchronize the ClearCase snapshot view with the git working tree, a do a clearfsimport (as in this answer) from that working tree to the ClearCase view: obnly the modified files are checked out/updated and checked in.
That way, I completely bypass the "hijacked/not hijacked" issue.
We are moving our code from CVS to ClearCase in order to consolidate our history in only one vcs system following the guidelines provided here http://www.ibm.com/developerworks/forums/message.jspa?messageID=13728313.
At first glance everything looked fine. All versions of all files appear to have been migrated, all branches and tags from CVS exist in ClearCase.
However not all files have branches created correctly (in my opinion). The example file.bat
has the following history (hope the ascii drawing is understandable).
1.1
1.2 --- SOME_TAG
1.3 --- SOME_OTHER_TAG
|---- BRANCH_1
1.4 --- BRANCH_2
|- 1.4.2.1
|- 1.4.2.2
Now, both SOME_TAG and SOME_OTHER_TAG is created and applied correctly in ClearCase. BRANCH_2 is created from CVS version 1.4 with version 0 on the branch having the same creation date/time as the CVS version 1.4. Which is good. Version 1.4.2.1 and 1.4.2.2 is created as version 1 and 2 respectively on BRANCH_2.
The problem is BRANCH_1 which is not created. As a minimum I would have liked to have the branch possibly only with version 0 on it.
I can see from the output of clearexport_cvs that the issue stems from here. The BRANCH_1 tag is not included in the output from clearexport_cvs command, only SOME_OTHER_TAG.
Any good ideas as how to rectify this? I couldn't find any options or switches on the clearexport_cvs command which seemed to help me.
It is important that we keep the original timestamp from CVS in order to be able to get the correct sourcecode for old builds. We used Parabuild so the only reference to CVS we have per build is similar to this "cvs update -P -A -d -D "2012-12-20 13:31:42 GMT" -r BRANCH_1"
Kind regards
Peter
If the clearexport_cvs doesn't work completely, and since there is no way to export only one branch, It is best to try fixing the import incrementally, and do a clearfsimport on a a dedicated ClearCase branch.
That would allow you to "patch" the history import with a few selected revisions from the CVS repo, but this isn't an automated process (unless you script the update of a CVS workspace, a bit like I did for Subversion).
I am trying to upgrade the commons-lang-2.0.jar to commons-lang-2.4.jar. When trying to add the 2.4 jar to the source control Clear Case is throwing the following error:
An element with this name (commons-lang-2.4.jar) has ALREADY been created in ClearCase for
this directory [lib], may be in a different version history of this directory that the one
you are seeing.
Review the version history of this directory [lib] to find it.
I feel this is because commons-lang-2.0 jar is existing in the lib folder and before adding 2.4 i need to remove 2.0. Can someone tell me if I am right? If so How can i remove 2.0 jar and replace it with 2.4?
That looks like a warning about "evil twins", in which your file commons-lang-2.4.jar was added, then removed from lib (and you would add it again, creating a new element with the same name, but a completely separate history: evil twin)
See also "Evil twin problem and subtractive merge".
See "About Evil twin" to try and find which version of lib already contains your file commons-lang-2.4.jar.
Once you have found the right version of lib, you can merge it to your current version of lib, restoring the deleted commons-lang-2.4.jar.
I'm using the Clearcase Remote Client 7.1.2 (and I only have it available)
I have a file which has 2 branches, branch1 and branch2. branch1 is configured to be the default branch in config spec. I want to checkout a version of the file from branch2, but there is no such option in Version Tree Browser when I click any version of the file on branch2. I can only checkout the latest version on branch1.
What am I doing wrong? Is there a configuration that will allow me to checkout any version I want?
A (CCRC web-)view is always defined to work at the latest version possible (LATEST) of a specific branch.
The CLI associated with CCRC doesn't include 'get' (presented in the second part of "In ClearCase, how can I view old version of a file in a static view, from the command line?"
If your view isn't an UCM view, you could add a selection rule at the start of your config spec (See CCRC edit config spec):
element /vob/path/to/file .../branch2/x
with x a version number from branch2.
However, I don't remember if you have access to the actual config spec source with CCRC.
You may want to create two views. One whose config spec selects versions in branch1 and another that selects versions in branch2. Use the appropriate view when checking out files.