In ClearCase, how do I find which developer activities were delivered in a specific delivery?
Doing
lscat -long
On either activity doesn't reveal this information.
See lsact (cleartool lsactivity):
List activities or baselines that contributed to the change set of an integration activity:
lsact/ivity -contrib activity-selector [...]
The activity selector must be:
activity:anActivityName#\aPVob # Windows
activity:anActivityName#/vobs/aPVob # Unix
A deliver activity would be named "deliver.xxx", and is the name of nthe activity recording all files modified during the deliver.
That will allow you to find back "Activity1" in the diagram above for the first deliver.
Try
cleartool lsact -contrib activity-name
while activity-name is a delivery activity
Related
I have a development view, which is linked to a development stream, which delivers to an integration stream.
What is the best way to find the integration stream using console commands ?
You could use a fmt_ccase query with cleartool describe, by looking at the UCM project:
cleartool descr -fmt "%[istream]Xp" project:myProject#\myPVob
If you don't have the project name ready, you can:
get the stream from your view
list all pvobs and find the one which includes said dev stream: the current project will be your project name, from which you can get the integration stream name.
If you CD or set into your view, cleartool lsstream -long -cview should tell you your default deliver target, which is usually the integration stream. If it's not, you can get the information from the project listed or by looking at the default deliver target...
Is there a way to list all files modified since last deliver with clearcase ?
I'm using clearcase like this :
ct setview <myStreamName>
Then I work on files. But before deliver to integration stream, I want to check all modified file. Is there a way to list all file with pending changes and compare them with working revision ?
Edit :
<myStreamName> is a child stream with activities, created from integration stream.
Actually, that isn't quite right. The simplest way to see your pending changes is to run cleartool deliver -preview -long while set in your development view.
This will list all the undelivered activities and the versions on those activities, regardless of the component.
You can use diffbl, more or less, but you then have to delve into the mysteries of deliverbl baselines (created on every deliver operation listing the activities delivered in that deliver.) and use those baselines as a filter on the activities... This then gets more complicated because you can deliver the same activity multiple times if you delivered it, did more work on it, and then haven't delivered the additional work.
Just use deliver -preview -long...
setview will mask your current view, since you access your files directly through /vobs/yourVobs/.../yourfiles (as shown here).
If you are doing a deliver, that means you are using UCM and have set a baseline from your current view, on your current stream (that you are about to deliver to an integration stream).
If that is the case, do a diff between two baselines: (cleartool diffbl -ver baseline1#\apvob baseline2#\apvob)
the latest one of the integration stream.
the one you have set
For the first element, use a ct lsbl -comp C -stream S to get the latest baseline.
This assumes you are delivering one component.
I also mention deliver -preview in "ClearCase Inter project delivery": it needs an UCM view on the target UCM stream to operate.
See also "I need a list of all the component of a certain stream that still needs delivery to default".
The error message:
Error: Target stream "myStream" requires child development streams
to rebase to recommended baselines before performing deliver operation.
means the deliver policy "Require development stream to be based on the project's recommended baseline(s) prior to delivery)" is in place.
See "How to force rebase before each delivery?"
Try and change that policy, or, as enforced, rebase first.
Then do a deliver -preview.
I have this file on code collaborator and I want to see the version tree of the file. how should I proceed to find the stream or activity where this file is attached?
The user guide mentions:
Support for ClearCase UCM
Collaborator supports ClearCase UCM activities. The change set associated with a
ClearCase activity can be added to a review using the Command Line Client addactivity command.
For each file in the activity, the latest version in the activity and the predecessor of the earliest version in the activity are uploaded to the review.
A Note about ClearCase Activities
Uploading activities for review generates file differences based on Multiple Version
Changelists
So it depends on how that file has been uploaded to CodeCollaborator, and if the "Multiple Change Changelist" name represents the UCM activity.
From the activity, you can then deduced the stream with fmt_ccase.
Who can lock/unlock/obsolete streams (or any other object) in a clearcase project? Do you have to be a privilaged user to perform these operations on streams that you didn't create?
The cleartool lock man page does mention:
unix: type/object owner, VOB owner, root
Windows: type/object owner, VOB owner, member of the ClearCase administrators group (which is the "privilege user": see "About ClearCase privileged users on Windows")
ClearCase privileged user is a designation referring to a user account that is a member of the clearcase group, which is granted ClearCase administrator rights when working in Full ClearCase.
Members of the clearcase group are granted special ClearCase rights.
Regarding Stream, a lock -obsolete Stream:xxx might be your only way to "remove" a Stream (especially if baselines were already created on it): see "Removing a UCM stream that has a delivered baseline".
Here are some examples for locking multiple instances of a same type of object.
To be sure a lock has actually worked, use the -fmt "%n %[locked]p\n" format when listing Streams:
cleartool lsstream -obsolete -fmt "%n %[locked]p\n" -invob vob
The OP Raihan adds in the comments:
According to the ClearCase documentation it it recommended to lock a stream before creating a baseline to prevent users from delivering during the process.
Isn't it overkill for a 'Project Manager' or 'Integrator' to have the root privilege who is managing a single UCM project (not necessarily created by him)?
Two things:
one, that means locking a stream with the -nuser option, in order to allow the integrator to perform operations (like making a baseline) on that stream.
two, if the integrator is not the owner an in... "integration" stream, then he/she asks the ClearCase administrator to give him/her the ownership of said Stream.
cleartool protect -chown integratorLogin stream:aStream#\aPVob
Far as I remember, you have to be one of the following:
Stream owner/creator
VOB owner
Member of ClearCase group
root (in UNIX \ Linux)
You may get further details by cleartool man lock
Can the project manager force cancellation of checkouts of files/directories made in any view/stream/project? How?
A ClearCase administrator can force all files of a given view to be considered as "not checked out" (which is the equivalent of canceling their checkout status), with cleartool rmview:
cleartool rmview -force -uuid (uuid_of_the_view) -vob \aVob
You can get the uuid by grepping the user in the output of:
cleartool descr -l vob:\aVob
See technote "Removing checked-out references of a view from a VOB".
It will work for any view (snapshot or dynamic views, base ClearCase or UCM views)
I would recommend limiting that command to a specific vob.
Anyway, that doesn't concern the Project manager unless he/she is also a ClearCase administrator (ie, he/she is in the same group than the ClearCase administrators group on Windows, or if he/she is root on Unix)
Regarding a cleartool unco (which you can attempt on a dynamic view only), keep in mind if will only work for:
Version creator
Element owner
VOB owner
root (UNIX and Linux)
Member of the ClearCase administrators group (ClearCase on Windows)
Local administrator of the ClearCase LT server host (ClearCase LT on Windows)
So, unless your project manager has created the Vob in which those checked out files are managed, he/she won't be able to undo checkout them.
As commented below, all checkout files of the associated vob \avob are no longer considered checked out (their status is reset, not their modified content, which is untouched).
In order to restore those checked out files, a user can:
for a snapshot view, list hijacked files (as in this technote)
for a dynamic view list eclipsed files (see technote on eclipsed files)
Each filename found can be piped to a clearcase checkout command.
So restoring the checked out files is fairly easy for a given view and vob.
You can't if it was checked out in a snapshot view. You may be able to if it was checked out in a dynamic view. You can use Find Checkouts to find checked out files and attempt to undo the checkouts from there.
Ideally, if it is a view that is accessible by someone with higher privilege, e.g. Clearcase administrator who possesses the VOB owner account, it is best to ask him to perform the checkin (if you are sure the file can be checked in) or a saving of the checkedout file followed by a "cleartool unco".
If it is not the case, the command
cleartool rmview -force -uuid (uuid_of_the_view) -vob <vob-tag-where-checkout-is>
should do the trick as mentionned previously by VonC.
However, be aware that this command cancel ALL the checkout in .
So if you have say :
\avob\file1.c
\avob\file2.c
Say both files are checkedout by the same view of the same user and you want to uncheckout only file1.c. The "cleartool rmview" command described above cancels ALL the checkout in the VOB. So file2.c will also be uncheckedout.
The good news is that the checkedout version will not be lost as they will stay locally in the absent user's view. He will be able to access them once he is back.
There is still another strategy how to handle other persons checkouts as an administrator. Gain access to the users snapshot view. If the computer is reachable, mount the snapshot location and use it as yours. In this case you may even checkin these checkouts as you see the changed files. Is the computer is unreachable, you can construct a new view.dat with the view UUID and populate your view with a cleartool update command for the critial files and directories. Changes in directory versions you will see and be able to checkin, file element changes are not reachable, so you have always to unco file versions.