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
Related
Allow the readonly access in a VOB for all users regardless of the ownership property of the user and the VOB.
You can check the technote "About read-only views":
In ClearCase 4.x and later the cleartool chview command is available to change the properties of a view.
The command offers both the -readonly and -readwrite (the default) options to switch the access mode to the view private storage. You must be the view owner or the root user on the view_server host to use chview.
See the cleartool chview command.
You can test the current status on your existing view:
cleartool lsview -prop -full dynamic_view
Note that with UCM, you also have the option described in "About UCM Modifiable Streams and UCM Read-only Streams"
Read only streams will never be associated with a branch type.
This means no versions can be created on the stream. No data will ever be delivered to or from the stream, only rebasing is allowed on a read only stream, which is to control the baseline (or versions) that
I received one request from one of our client regarding "group permission change for listed folders" from “abc” vob as they are not able to change permission due to mastership issue for those folders (Because, mastership lies at our end).
I got request to change the group permissions for our vob's 10 directories. So that they can access and do some analysis through some tools.
But as per our admins, VOB group permissions remains to one group only and they cannot change it.
But our Client is keep on pinging me. As per my R&D, I found "protectvob" command. Does the below command works?
cleartool protectvob –add_group "groupname" /path_of_the_vob/abc_vob/directory1
Please could you check and send me the steps to change group permission for only 10 directories of abc vob?
protectvob will allow you to add secondary groups to the Vob.
But it won't change the protection on any element within that Vob.
See the examples of cleartool protectvob man page.
To change a group on a collection of files, you can use cleartool protect (once you have added that group to the secondary groups of your vob, so protectvob is still needed):
cleartool find . -nrec -exec "cleartool protect -chgrp \"My Group\" \"%CLEARCASE_PN%\""
(adapt the cleartool find to list only what you need)
I am receiving the below error when I am trying to edit the value of Proj_Mgr in UCM.
Please advise
no permission to perform operation "Make attribute" UCM
You must see an error like:
No permission to perform Make Attribute.
Must be one of: member of object group, object owner, VOB owner, member of admin group
So check your CLEARCASE_PRIMARY_GROUP environment variable, and compare it to the groups of the vob, or the associated pvob (in UCM).
You can see those by describing the vob:
cleartool descr -l vob:\myVob
As a possible cause, check out the IBM technote
"Problems that occur if the ClearCase Administrator group owns the VOB or VOB objects":
When a VOB or objects contained within a VOB (elements and metadata) are owned by the ClearCase Administrators group, this will most certainly result in permissions errors whenever an operation is performed against that object by a non-Admin user.
Since the administrators group by default has access to all ClearCase objects, it is not necessary to explicitly add that group and should be avoided.
You can see a concrete scenario where that error pops up in:
"Error setting the recommended baselines for this stream" (for a Stream though. In your case, you shouldn't have to reprotect the Vob, but rather make sure you have the right identity/group).
I used this command to solve this issue (a protection issue as described above):
ct protect -chgrp ccuser project
I am getting following
Rational ClearCase Explorer
---------------------------
Error checking out 'C:\Projects\TestServlet.java'.
Lock on activity "activity_test_name" prevents operation "change activity".
Unable to check out "C:\Projects\TestServlet.java".
The correct procedure to allow you to checkout that file would be to include you in the list of users exempted on that lock: see cleartool lock man page.
But you need to be the owner of the pvob in which the activity or the current Stream has been declared, or root (or privileged user on Windows).
If the activity only is locked, another way would be for you to create another activity.
cleartool mkact anotherActivity
and try your checkout then. It should have unset the current (locked) activity, and set a new one.
But if the Stream itself is locked (or even the vob/pvob), then you need to ask your ClearCase admin for an unlock.
See for instance IBM technote "Lock on activity prevents operation change activity", which illustrate how that "activity locked" error message is, in this case, misleading.
But that was for CC2003, and I suppose you are using a more recent version of ClearCase.
Someone with administrative control over the VOB you're using has locked the activity so that you cannot make a check-out. Speak to the people in charge to find out why.
The problem is (most probably) not that you don't have permission in general to do it. And you get a different error if the VOB is locked for backup.
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.