1. How do I find all view private files in my view?
cleartool ls -r -view_only
This restricts the listing to objects that belong logically to the view: view-private files, view-private directories; checked-out files.
NOTE: Checked-out directories are not listed.
For more information run “cleartool man lscheckout” from the command line.
cleartool ls -r -view_only | find “.java”
cleartool find -all -version “version(…/private_branch/LATEST)” -print
For more information run “cleartool man find” from the command line.
cleartool find . -type f -print
cleartool find . -type l -print
From Clearcase Explorer if you have a view that is referencing the branch right click on the view name and click “Find Checkouts”.
From the command line (within a VOB/view context – the view does not have to reference the branch):
cleartool lsco -brtype branch_name -r -l
cleartool lsco -brtype branch_name -r -l -cvi (checkouts which are in the current view only)
cleartool lsco -brtype branch_name -r -l -me (only my checkouts)
For more information run “cleartool man lscheckout” from the command line.
8. How do I see the changes made to a branch between two specific dates?
From the command line
cleartool find -all -ver “brtype(branch_name) && created_since() && !created_since(” -print
cleartool find -all -ver “brtype(test_3.1_main) && created_since(12-Dec-03.01:00) && !created_since(30-Dec-03)” -print
and created by Mark:
cleartool find -all -ver “brtype(ep_3.1_main) && created_since(12-Dec-03.01:00) && !created_since(30-Dec-03) && created_by(Mark)” -print
9. How do I find all changes made on a integration branch since the last release?
If the label associated with the last release it known then run the following command in a view context.
cleartool find -all -ver “version(…/integration_branch_name/LATEST) && !lbtype(LABEL_NAME) && !version(…/integration_branch_name/0)” -print
e.g. cleartool find -all -ver “version(…/test_5.1_main/LATEST) && !lbtype(TEST_126.96.36.199) && !version(…/test_5.1_main/0)” -print
From the command line in a view context run the following command:
cleartool find -all -ver “lbtype(LABEL1) && !lbtype(LABEL_2)” -print
cleartool find -all -cvi -nxname -type f -print | ccperl -ne “chomp; print qq($\n) if -z ($); “
12. How do I see all recent modifications to a VOB
ct lshistory -all -since -user
since a certain date by all users of the VOB
ct lshistory -all -since 12-Jan-05
since yesterday by all users of the VOB
ct lshistory -all -since yesterday
list only those modifications made by mark (note userid is case sensitive):
ct lshistory -all -since yesterday -user mark
13. How do I find checkouts by a single user?
For an individual
Right click on the VOB name in Clearcase Explorer > History
From the toolbar select File> Open > Go to any view directory > Select>
Check “Recurse through subdirectories” > OK
From the first pull down menu on the toolbar select the user’s private branch.
14. How do I set my config spec to look at elements with a particular label?
Set your config spec to look like this
element * CHECKEDOUT
element * LABEL_NAME -nocheckout
element * /main/0
Line 1: Select any checkouts in my view. This line is always required by clearcase even if you do not plan to checkout any elements in the view.
Line 2: For all other elements in the VOB select any elements which have label LABEL_NAME attached to them. Do not allow me to checkout elements with this label.
Line 3: For all other elements in the VOB select version zero – the empty version of the element.
Run the following from within a view
cleartool find -all -version “lbtype(MY_LABEL)” -print
In some version-control systems, only one user at a time can reserve the right to create a new version on a branch. In other systems, many users can compete to create the same new version. Rational Clearcase supports both models by allowing two kinds of checkouts: reserved and unreserved.
The view with a reserved checkout has the exclusive right to check in a new version for a branch. Many views can have unreserved checkouts. An unreserved checkout does not guarantee the right to create the successor version. If several views have unreserved checkouts, the first view to check in the element on a branch creates the successor; developers who are working in other views must merge the checked-in changes into their own work before they can check in.
The figure below illustrates checked-out versions created by reserved and unreserved checkouts, and the effects of subsequent checkins.
With a reserved checkout, a checkin of version 3 creates the latest version on the branch, version 4. With an unreserved checkout, the first checkin creates the latest version on the branch, version 4. But a subsequent checkin of version 3 is blocked until the user merges the latest version, version 4, with the checked-out version.
When Rational Clearcase loads a file element into a snapshot view, it applies the file system read-only attribute to the file. If you change this attribute and modify a loaded file without checking it out, Clearcase considers the file hijacked. Only loaded files can be hijacked; view-private files are not under Clearcase control and you can modify them without involving Clearcase.
Hijacking takes a file outside direct Clearcase control. Although the update operation detects whether you have hijacked a file, we recommend that you do not hijack files as standard practice.
Note: You can hijack files only in a snapshot view; you cannot modify a version in a dynamic view until you check it out.
Directories and Hijacking
Hijacking does not apply to directory elements. You can create view-private files and directories without having to check out the parent directory. However, the only way to add or remove elements from source control is to check out the parent directory.
In CC Explorer right click on the view name and select “Find Modified Files”
Under “Details” check “Display results when closed”. When finished a View Update
Window will appear with details of any hijacked files.
In the right pane of the Snapshot View Update window, right-click a hijacked file.
On the shortcut menu, click Compare with Original Version.
To keep the modifications in a hijacked file, check out the file:
1 In the right pane of the Snapshot View Update window, right-click a hijacked file.
2 On the shortcut menu, click “Check Out”.
3 Clearcase treats a checked-out hijacked file as it does any other checkout.
When you are ready, you can check in the file.
If, for specific hijacked files, you want to discard your changes and get a fresh copy of the version from the VOB, you can undo the hijack.
1 In the right pane of the Snapshot View Update window, select one or more hijacked files.
2 Right-click the selected files, and click “Undo Hijacked File”.
Clearcase overwrites the hijacked file with the version that was loaded originally in the view. Update the snapshot view if you want the very latest version of the element as specified by your config spec.
To keep track of file modifications in a snapshot view, Clearcase stores the size and last-modified time stamp of a loaded file (as reported by the Windows file system). Clearcase updates these values each time you check out a file, check in a file, or load a new version into the view.
To determine whether a file is hijacked, Clearcase compares the current size and last-modified time stamp of a non-checked-out file with the size and time stamp recorded in the view database. If either value is different from the value in the view database, Clearcase considers the file hijacked.
Changing the read-only attribute of a non-checked-out file does not necessarily mean Clearcase considers the file hijacked.
23. What does “Checked out but removed” mean?
In Clearcase Explorer, I see a file with coloured questions marks next to it. When I hover over it, it say’s “Checked Out but Removed”.
“Checkedout but removed” indicates that a file is recorded as having been checkedout by the VOB database, but that its corresponding view private file was subsequently removed.
This usually happens because the file (FILE1) is actually a symlink to another file (FILE2), which is checked out.
If this is the case
When FILE2 is checked out, Clearcase copies a view private copy of the checked out file to the file that was checked out (FILE2 in this case). However, because FILE 1and FILE2 in reality reference the same internal storage element, Clearcase therefore thinks that FILE1 has been checked out (which is correct) and removed (which is technically correct, since Clearcase did not copy a view private version of the checked out file to FILE1).
Right click on the element name> Symlinks > Symlink Target Operations
Checkin or uncheckout the target element.
If the element is not a symlink then one way to recover from this is to do a ‘cleartool unco’. The other way is to copy a file with the same name into that directory. Note that any work on the checked out copy of the file cannot be saved, because there was no view private copy of the file in which the contents were stored.
- Use of runtime variables to save into another variable using register in Ansible - September 6, 2018
- Ansible & Ansible Tower Variable Precedence Hierarchy - September 6, 2018
- How to use template in Ansible? - September 6, 2018