I am building a jar on my unix server using clearcase , Now I want to see, the last jar i.e jar without my update . Can I do that in clearcase if yes can someone suggest what is the best way to do that ?
ClearCase only allows you to access the sources from which you are building your jar.
You can create a second view which you can configure to see a tag representing your sources before your modifications, assuming you did put a label on your sources before modifying them.
element * CHECKEDOUT
element * yourLabel
element * /main/LATEST
Even if you didn't put a label, you can still set a time-based selection rule.
Related
Using clear case reporting wizard how could i retreive the list of unlabelled files in a branch from a specific date?
You would need first a view configured to select element on that specific date: use a time-based selection rule config spec:
element /myPath/... /main/{!created_since(16-Sep-2009)}
element /myPath/... /main/LATEST
I would recommend a dynamic view for that, as you can easily tweak said config spec until you see the versions you want, and quickly refresh the view after each config spec modification.
Once the view is properly set, you can use:
a simple find query to list all version not labelled with a specific label
or try the ClearCase reporting wizard, after having to select first the appropriate script (which are in C:\Program Files\Rational\ClearCase\reports\scripts, like mentioned in this thread).
I suspect it is easy to configure those scripts to report all labelled versions, I don't know if you can report the "negative" form (all non-labelled version for a given label).
I am not been able to check out file in this specific pc because it compalins abt
cleartool error: type manager "text_file_delta" create_branch operation.
cleartool error: unable to create a branch request by -mkbranch option in config spec.
cleartool error: unable to check out
config_spec:
# ONLY EDIT THIS CONFIG SPEC IN THE INDICATED "CUSTOM" AREAS
#
# This config spec was automatically generated by the UCM stream
# "space_reload_CA" at 2013-09-06T16:13:58-04:00.
#
# Select checked out versions
element * CHECKEDOUT
element "[03d13482d8a611dc9c17000183b043eb=/space_tff]/.../..." -nocheckout
element "[03d13482d8a611dc9c17000183b043eb=/space_tff]/.../..." -nocheckout
element "[975cd291464411df86be0001843ab215=/space_tff/.../..." .../space_reload_CA/LATEST
element "[975cd291464411df86be0001843ab215=/space_tff/.../..."
-mkbranch space_reload_CA
element "[975cd291464411df86be0001843ab215=/space_tff/.../..." /main/0 -mkbranch space_reload_CA
end ucm
#UCMCustomElemBegin - DO NOT REMOVE - ADD CUSTOM ELEMENT RULES AFTER THIS LINE
#UCMCustomElemEnd - DO NOT REMOVE - END CUSTOM ELEMENT RULES
# Non-included component backstop rule: no checkouts
element * /main/0 -ucm -nocheckout
#UCMCustomLoadBegin - DO NOT REMOVE - ADD CUSTOM LOAD RULES
# Component selection rules...
That looks like the IBM article "Element already has a branch of type"
The actual error is:
%>cleartool co -nc a.txt
Created branch "branch" from "a.txt" version "\main\1".
cleartool: Error: Element already has a branch of type "branch" ("\main\branch").
cleartool: Error: Unable to create branch requested by -mkbranch option in config spec.
cleartool: Error: Unable to check out "a.txt".
The cause can be:
a time issue (cause 1, 2 and 4 below): The OP user2370590 mentions a possible remedy:
rebooting will resolve such type of issue
a syntax error issue (cause 3 below)
Syntax errors are usually the cause, except in your cause this is an UCM view, meaning its config spec is automatically generated by ClearCase.
Just to be sure, type:
cd /path/to/your/view
cleartool chstream -generate
cleartool setcs -stream
That will force the config spec of your view to be regenerated according to the configuration of your Stream.
And try again your checkout.
Cause 3:
The error will occur due to a number of config spec syntax problems:
Incorrect spelling of scope, pattern, or version-selectors.
For example CHECKEDOUT or LATEST or label names or branch names
Incorrect ordering of the scope, pattern, or version-selector.
For example forgetting to include a LATEST rule that references a -mkbranch rule.
Metadata "types" not created but referenced in config spec.
For example a -mkbranch rule referencing a branch type that does not exist.
A directory is listed using windows style slashes("\" instead "/" ) in Unix/Linux systems
(Note: in a config spec, always use "/": it is easier, and it works both on Windows and Unix.
Solution 3: Fix syntax
Ensure the syntax is correct in the config spec.
Cause 1: time sync issue
This error is caused by the view server and VOB server time not being in sync.
If the time (clock) on the VOB server is greater then the view server this error will happen as the version is created with a time stamp that is seen as in the future by the view server and thus will not be loaded (snapshot view only).
Solution 1: Fix time
Correct the time on the view and VOB server so they are in sync.
Review the operating system instructions on how to modify the system time.
Cause 2 VMware issue
This error can happen when using ClearCase on a VMware® hosted machine.
The cause of the error is related to the time setting on the VMware server. If the time on the VMware server is behind that of the VOB server, then the mkbranch error will occur.
Solution 2: Fix VMware time
Ensure the time on the VMware server is in sync with the VOB server.
The following command is one method that may be used on the VMware server to synchronize the time with that on the VOB server.
net time \\vob_server_name /set
Cause 4: Replica migration
In one case, the exporting VOB had been moved from one host to another. Instead of following the move procedure outlined in the Administration Guide, the VOB was copied to the new host.
This left the VOB active in two places. One developer created a branch type in the original location. After starting to work with the copied VOB at the new location, the developer detected that the copy did not contain the latest mkbranch operation. The developer decided to run the mkbranch operation again.
The importing site got the synchronization update packet with the first mkbranch event and imported it.
Then the packet with the second mkbranch event arrived but could not be imported because the branch already exists; hence the error.
Solution 4: Fix replica
This is divergence as both replicas, the sending and the receiving site, do not agree on the date and time of the mkbranch event.
One of the replicas will need to be removed and recreated. Which one to remove depends on the size of the replica family, the synchronization pattern in use and the willingness to lose data in that replica.
From a snapshot view using base ClearCase, I want to checkout the latest version of a file from a branch that is NOT selected in my snapshot view. I would expect this to be possible, because you can do it from the version tree browser tool.
However, the documentation for the checkout command claims that you can't do this in a snapshot (emphasis mine): [edit: Yes you can! See below.]
Nonstandard checkouts
By default, the checkout command checks out
these versions:
The most recent version on a branch, if you are using a dynamic view
The version currently loaded in the view, if you are using a snapshot view
To modify a different version, you can either use the –version option or create a subbranch at that version. (See the mkbranch
reference page). Furthermore, from a single view, you can have only
one checkout per element at a time.
Note: When you work in a snapshot view, the only version of a
directory element that can be checked out is the version currently
loaded in the view. Therefore, the –version and –branch options do not
work.
How can I check out an unselected version from the command line?
[edit: Here I misread the "Note:" section. What the help means is that directories can't be checked out using the -version or -branch args, but normal files can be.]
The actual solution selected by the OP dss539 is to use cleartool checkout directly (see cleartool checkout man page)
cleartool checkout -bra/nch branch-pname | -ver/sion
It would work for files (not directories) in dynamic or snapshot view.
If you don't want to modify the config spec of your current snapshot file, then you can:
either use a separate view (a dynamic one in order to have the right version immediately selected), and modify at will the config spec of that other (dynamic view),
And copy the version back to your snapshot view.
See also "How would you select versions from a specific branch in ClearCase?" for config spec example.
...
Actually, you don't even need to modify the config spec of that dynamic view:
You can use the extended pathname of the version you want to directly access and copy the right version.
or use the cleartool get command (which is what "Send To" is doing on the version Tree).
See "clearcase command to backup predecessor version of a file?"
(You don't need a separate view here)
Is there a way to set up a single stream/view that can be used to build releases from any existing baseline (new and old) on any stream of a ClearCase UCM project?
What I usually use is a base ClearCase dynamic view, in order to quickly change baselines in its config spec.
A baseline is a label put on every files of a component, so the config spec would be:
element /vob/Component/... MY_BASELINE
element * /main/LATEST
Note that it will only work with fully labeled baselines (and not incremental baselines)
You can use also a snapshot view, for the compilation will be quicker (but you will have to support the update download time)
I am using eclipse clearcase remote client. Everytime i wish to check out the file, i am going into the long branch.
Is there any way to find a file directly in the root like searching?
If you are using CCRC, you are using a snapshot view, which have an config spec specifying:
what you are selecting (this is the part you need to adjust to check out the right version in the right branch)
what you are loading on your disk.
As mentioned in this comparison matrix between CCRC and other ClearCase instances,
CCRC can only search the local copy area’s database for checkouts, hijacks, view privates.
I would recommend making a second CCRC web view, and make some tests on that view (with a small set of files loaded).