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.
Related
Is there anyone who knows a way to find all added files in a CCE view? just to verify that no file is missing before applying label.
thank you.
No file missing means some files might be still in checkout mode, but even then, applying a label would be applied on that checkout version (you would need to make sure and checkin them later)
You can list files still in checkout here.
A better query would be to list all files with versions more recent than the previous label (assuming base ClearCase here, not UCM)
You can use the date for instance to list all files with version newer than a date
ct find -all -type f -version "{created_since(11-apr-2013) && brtype(branch_name)}" -print
That way, you will know all added files, and can check if there are any missing before applying a label.
The OP Frimus proposes an alternative solution in the comments:
I resolved the issue by creating an other view with the same config spec,
and I compare the two views.
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
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 need to get a list of user names for every version listed in the version tree of an element, and then repeat for every element in the directory.
So far, I have come up with the following:
> cd M:\path\to\folder
> cleartool find . -version "created_since(01-January-1979.00:00:00)" -exec "cleartool describe -fmt ""%Lu\t%Fu\t%n\n"" %CLEARCASE_XPN%"
I chose a really old date thinking our VOB is younger than that date.
This gives me the same information for every version of an element because it's looking at the element owner, not the individual that contributed a specific version.
I'm using the following pages for reference:
http://www.ipnom.com/ClearCase-Commands/describe.html
http://www.ipnom.com/ClearCase-Commands/fmt_ccase.html
http://www.ipnom.com/ClearCase-Commands/find.html
http://www.ipnom.com/ClearCase-Commands/query_language.html
This might be a simple case of RTFM. Any help is appreciated.
You need to check if %n (used in the -fmt_case directive) returns the element name of the version name:
if it is the element name (without any extended path information, as in ##/main/.../x), then it would be normal for the cleartool describe to return always the same information.
if it is the extended path, as I would expect with %CLEARCASE_XPN%, then %u should be the user associated with the event (the version), and not the "element owner)
%u
Login name of the user associated with the event.
Small note, I always prefer using double-quotes around %CLEARCASE_XPN%, in case the path filename has a space in it.
-exec "cleartool describe -fmt ""%Lu\t%Fu\t%n\n"" \"%CLEARCASE_XPN%\""
Upon closer inspection, it looks like the command I posted above is sufficient. I saw a bunch of user names that were the same and thought they were all the same, but that's not true. I'm seeing different user names for different versions of the same element as I originally wanted.
If you work on a multisited VOB, do not forget that the owner of an object created on another site will be the VOB owner on your site. Therefore, if an object was created and modified only in a remote site, all of its tree and version would be owned by the VOB owner.
Of course, I assume you are in non preserving mode for identities for your replica synchronization (see the Changing preservation mode for mode infos). In most cases, you would not want replication to preserve identities, because each site has its own set of users.
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/...