I am trying to rebase a baseline using this command in ClearTool:
rebase -bas [baseline_code]
However, after this command, a screen pop up with this question:
Do you wish to name the Deliver/Rebase activity (if no, press Enter or Cancel to use the default name)
I want to avoid this screen because I want to implement it in a code, for this reason, is there any command to add in this rebase, then it can stop to show this screen? Or is there any kind of set up that I have to do in ClearCase to stop to show it?
My ClearCase version is 9.0.1.0.
I tried to disable some trigger that I found as suggested.
However, I was not allowed because I am not part of the ClearCase group or object owner.
For this reason, a college of my work gave this tip to create a read-only child streams, that avoid to show the message (screen). And it worked.
mkstream -in "stream parent" -readonly "stream name"
After that, I could do:
rebase -bas "baseline"
rebase -complete
Since the message "Do you wish to name the Deliver/Rebase activity" does not seem to be a standard/native one, it is possible it comes from a trigger.
From there, see "How to disable a trigger in a VOB or determine if an existing trigger is already disabled"
Check its list with cleartool lstype:
cd/path/to/my/view/myVob
cleartool lstype -invob \aVob -kind trtype
Related
Is there any command which will display all the information associated with a particular activity branch. Like:
On which label it was created?
On which label currently it is?
What are the files are checked in the branch. What are there latest versions?
Who created this branch?
Is there any single command for all those which will display these information (not in graphical view)
The only two commands are:
cleartool lsact
cleartool descr -l activity:anActivity#/apvob
You can get that way the list of versions for each file.
See also "Cleartool command to list all files part of a changeset"
You can combine the second command (descr) with a -fmt (fmt_ccase) directive in order to get other activity attributes, like its associated view (from which you can deduce the stream)
But that won't give you from which label the activity started. For that, you can list the foundation baseline of the stream.
And that won't give you "On which label currently it is?": the activity list versions. The fact that those versions are or are not labelled is not relevant for the activity. You would need to describe the version in order to see if it has a label attached to it.
If this is UCM, and by "activity branch" you mean the stream it is on, you can get the information about the stream by using cleartool lsstream -long -cview while in the view in question. The output will look something like this:
stream "brian_testrep1_2"
2017-08-17T17:50:15-04:00 by Brian.None#DESKTOP-LQ0QA86
owner: DESKTOP-LQ0QA86\Brian
group: DESKTOP-LQ0QA86\None
project: testrep1#\testproject (development stream)
default deliver stream: testrep1_Int#\testproject
development streams:
contains activities:
foundation baselines:
test_2#\testproject (testcomp1#\testproject) (modifiable)
recommended baselines:
views:
Brian_testrep1_2
policies:
...
I'm new to CC and I'm coming from Git and Mercurial background, probably thats why ClearCase confused me so much. I've been assigned a task to migrate latest CC's revisions to Git. Problem is that I couldn't manage to checkout any branch other than main in CC.
I have a view that displays all VOB's /main/LATEST revision. I assume, main branch's latest revision.
element * CHECKEDOUT
element * /main/LATEST
Now I need to get the list of other branches in a particular VOB. To do that, I navigate from terminal in that folder and run
cleartool lstype -kind brtype -invob /%VOB_NAME%
and I can see the list of branches. Correct me if I'm wrong, but I assume, it displays only the branches relevant to VOB(%VOB_NAME%).
Now I need to checkout the branches. What is the standard way of doing this. I tried updating config spec with something like:
element * /%VOB_NAME%/%BRANCH_NAME%/LATEST but it doesn't seem to work.
Pretty sure I'm not doing it correctly.
Also for migration purpose, I'll need to automate the steps to acquire branches and checkout the branches. I guess updating config spec to switch branch in a view takes some time and probably is an async operation, so is there a way to determine when view finishes updating?
Or maybe there's command line option to switch branch for a particular VOB in a view?
So in short, here's my questions I'm struggling with:
Than
Am I acquiring VOB branches correctly?
How can I checkout a particular branch?
Is there a way to determine when checkout finishes?
thanks
UPDATE
ok I tried #VonC's recommendation so my config spec looks like this:
element * CHECKEDOUT
element * .../heine_1/LATEST
element * /main/LATEST
If I'm guessing correctly, one VOB containing branch named heine_1 should checkout that particular branch, the rest of VOBs will stay on main branch, but this is not the case. When I run cleartool ls inside that VOB, its still on main branch. All folders are postfixed with Rule: /main/LATEST. So I guess it didn't switch the branch.
Thanks
There are a few questions in the original question and the comments.
Addressing the configspec issue first...
The syntax of an element rule is:
element {path} {version rule} {optional clauses}
If you need a VOB-specific rule, you can do something like this:
element \myvob\... ...\myvobbranch\LATEST
element \myvob\... \main\LATEST -mkbranch myvobbranch
The "..." in the path means "this location and everything underneath it."
The "..." in the "version rule" means that the branch name is at the end, so this would match /main/myvobbranch/LATEST, /main/br1/myvobbranch/LATEST, etc.
If you're working on a branch, you generally want new files or work to appear on the branch you are working in, and the second line makes that happen.
Everything in a configspec is case sensitive, so be aware that "LATEST" is not "latest."
Since the view was created for you, I'm reasonably certain that it is a dynamic view. If it is mapped to a drive, it's definitely dynamic. If you need to know for sure, you can CD into the "working area" of your view and run "cleartool lsview -pro -full -cview" and look at the "attributes" line. The line for a dynamic view will look like this:
Properties: dynamic readwrite shareable_dos
On the direct questions:
Yes, you are acquiring the branch list correctly.
By default the checkout is done using the version selected by the view, you can use cleartool checkout -branch {full branch path} {file name} to check out the latest on a branch, or cleartool checkout -version {version id} {file name} to check out a version other than the latest on a branch. I would not recommend either as a normal practice. The -branch will cause checkins to go to the element's parent branch. The -version would require add a requirement to perform a merge to get the checkin to complete, which would also go to the version's parent branch.
Checkout is finished when the command finishes.
A big "new user gotcha" is that directories are also versioned objects. If you're adding files to source control, you need to remember to check the directory in so that they are visible by others with similarly configured views. The ClearCase GUIs have this behavior as a default if you started the process with the directory NOT checked out, but not if you explicitly checked out the directory beforehand.
I am a beginner with CleaCase.
The view i was working in is now deleted, post delivery of the code changes. Only thing that is accessible now is activities.
I can get the list of activities by issuing "ct lsact " on the Integration Stream SDS
I have the following info from which i want to know which activity has my changes
--12-24T20:13 user create version "/vob/abc/xyz/mno/src/hello.c##/main/abc_1.0_integration/ver_2.0_integration/Mars_plm_1.0_SDS/**7**" (VER_2.0_BL21_09_01_2014_13_43.9104, Mars_abc1.0_mysqldb_07_01_2014_15_01.5788, VER_2.0_BL21_27_12_2013_19_07.4516, VER_2.0_BL21_24_12_2013_20_13.4521)
I want to find out which activity has the below version of the checked in file.
/vob/abc/xyz/mno/src/hello.c##/main/abc_1.0_integration/ver_2.0_integration/Mars_plm_1.0_SDS/7
Thanks in Advance
You can try and use cleartool describe to see if the activity is displayed:
cleartool describe -l hello.c##/main/...
Using fmt_ccase options, you can display the activity directly:
cleartool describe -fmt "%[activity]p" hello.c##/main/...
Does anybody know why comments that were applied to a chact (or any other command on an activity) don't show up when I do lshistory? Is this the wrong command to get comments?
I just want to see the comments applied to an activity. For instance, I tried the following:
ct chactivity -c "My new comment" -headline "Test headline" activity:...
The headline changed just fine on the activity, but when I do the following:
ct lshistory -l activity:...
I only ever see one event - the "create activity" event
Am I looking in the wrong place for comments? Or is it possible this kind of commenting is turned off in ClearCase somehow?
Thanks!
If you look in event_ccase CC7.x (even in 8.x), you will see that cleartool chact itself does not generate a minor event.
However, changing the comment of any object does.
When you supply comments to a ClearCase command, your comment becomes part of an event record.
Some cleartool commands create a comment even if you do not provide one.
These generated comments describe the operation in general terms, such as “modify metadata” or “create directory element.”
User comments, if any, are appended to generated comments.
It is, as you have noted, a "minor" event, visible with cleartool lshistory -minor.
Apparently you have to specify -minor in the lshistory and then all of the events (and their associated comments) show up.
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).