What would be the command to check the existence of an element (say named "XYZ") in a Clearcase VOB ?
You can start with cleartool describe:
clertool describe yourView/yourVob/yourFile
But that implies that you have a view first.
I would recommend a dynamic view, as it is easier/quicker to set up and use (no update like in a snapshot view).
Related
I an new to ClearCase and started studying the ClearCase documentation.
UseCase : I have two branches - 'Branch_A' and 'Branch_B'.
I need to merge all my changes from 'Branch_A' to 'Branch_B'
I won't be able to use the ClearTeamExplorer, so only option is command line.
I read the documentation and its mentioned that cleartool findmerge command is the option for it.
But there is no direct example given for this.
Could someone please provide an command line example for this please?
Any help on this is appreciated.
Assuming a base ClearCase view/branch (no UCM views/Streams):
cleartool findmerge include a relevant example:
for the current directory subtree, compare versions visible in the current view against versions on another branch and perform any required merges.
cd /path/to/target/Branch_B/view
cleartool findmerge . –fversion /main/Branch_A/LATEST –merge –gmerge.
The idea is to be in the view set on the target branch, with a config spec ready to create new versions.
element * CHECKEDOUT
element * .../Branch_B/LATEST
element * /main/0 -mkbranch Branch_B
element * /main/LATEST -mkbranch Branch_B
The merge is done in the target view, on the target branch.
Now if you are using UCM, then the view done on a Stream has already the right config spec.
The idea remains the same: Execute the findmerge in the target view (after setting a dedicated activity, to record that merge)
In that case, check "How to merge changes from a specific UCM activity from one ClearCase stream to another"
You do not merge branches in UCM, you would merge UCM activities.
I have a file in lost+found which is checkedout but I do not see any viewreference. How can i remove the file?
I'm Checking in windows system. When I do a version tree, I see a view that was created in some unix system. I'm not able to get the uuid of the same.
How can I delete such file?
For the checked out state, You should be able to get the view uuid in the same way as in the previous question "How do I delete check-outs from a particular view in clearcase?".
That lost+found folder is part of a vob and a cleartool describe -b vob:\Avob should list the uuid of the unix view.
But if you are not sure which uuid matches the actual name of the old view you see in the version tree, you can check for that name directly in the registry server.
There are different option:
cleartool rgy_check -views
But also, since I have access to the registry server, I can do a simple grep of the name in the var/rgy folder where view_tag is:
<user>#<server> /path/to/ClearCase/var/rgy
$ grep -i <view_name> view_*
view_object:-entry=view_object;-hostname=server;-local_path=path/to/<view_name>.vws;-owner=<name>;-view_uuid=e670fe8a.fb0540e5.83f4.7f:82:a6:s8:e1:1a;-attributes=sumview;
view_tag:-entry=view_tag;-tag=<view_name>;-title=<title_View>;-hostname=server;-global_path=\\server\views\path\to\<view_name>.vws;-region=<region>;-view_uuid=e670fe8a.fb0540e5.83f4.7f:82:a6:s8:e1:1a;
That way, from then name, you get back the uuid and can remove the checked out state from the vob.
Regarding the file itself (in lost+found), see technote "About the lost+found directory", that I mentioned in "How do I retrieve a file if I undid a folder checkout in ClearCase?".
There are two possible ways to remove an object from the root of the lost+found:
The object can be moved to a new location in the VOB using the cleartool mv command
The object can be permanently deleted from the VOB.
Be careful with the second option (which involves rmelem), especially in UCM (where that object could have in previous versions baseline labels attached to them)
When I execute a "cleartool ls filename##specificVersion", I see
filename [not loaded]
What does this mean?
For background information, I was trying to also execute a cleartool mkbranch, and was a "Element not found" error. So, for a sanity check, I tried a cleartool ls.
"not loaded" means the file:
is selected (by the selection rules element * ...) but:
not loaded by the load rules (load /xx/yy...)
You can see both sets of rules by doing a cleartool catcs anywhere within your view (or cleartool edcs to edit said rules)
This is typical of a snapshot view, which is the only one having "load rules" (as opposed to a dynamic view)
See:
"Before accessing files not loaded into snapshot views":
A snapshot view contains only the set of elements that you specify in the load rules of your view. (In UCM, by default, your view loads all of your project source files.)
When you restrict the scope of a view, it contains only a subset of elements in the VOB. During the course of a development cycle, you may need to see a version of an element that is not loaded into your snapshot view.
You can view nonloaded files or copy them into your view for build purposes, but you cannot check them out. Only file elements that are loaded into your view can be checked out.
"To copy a nonloaded element into a snapshot view"
cleartool get -to filename path
cleartool get -to prog.c.previous.version prog.c##/main/v3.1_fix/10
Is it possible to remove a dynamic view out of a particular clearcase region?
cleartool -rmview seems to not take a e.g. -region parameter and I was wondering whether there's a more elegant way to achieve this.. or is the only way to change the system's CC settings?
If you want to remove a view from a region, that means you don't want to erase it completely, as it still has to work in other regions.
In that case, the right command is:
cleartool rmtag -view -tag dynamic-view-tag -region theRightRegion
See rmtag command:
The rmtag command removes one or more entries from the network's view tag registry or VOB tag registry
A rmview would both math a rmtag, and un-register the view id (and remove any local trace of the view, like removing the view storage).
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.