What I understand is that,
PVOB is a special type of VOB that is used when UCM is
implemented as the software configuration management process.
But my doubt is how is it different from VOB? I am new to CC but, as far as I know, even PVOB contains the same information as VOB.
Can anyone explain me?
PVob is like a vob in that it can version files and folders.
But by convention, you don't use a pvob to "add to source control".
You use a PVob as a "admin vob" for a classic Vob in order to declare component(s) in it, and to manage all the matadata associated to UCM:
Projects
Streams
Activity
Merge Hyperlinks for deliver and rebase
In that case, as I mentioned here, PVob are visible in the ClearCase project Explorer, not the ClearCase Explorer.
As any "AdminVob", a pvob manages datatypes for the associated vobs: see "VOB datatypes and administrative VOB hierarchies".
Simply, a pvob will manage UCM types as well, making projects, streams and activities visibles for all the associated UCM vobs (which contain the actual data).
You can actually group pvob in a hierarchy, as explained in "Multiple PVOBs and a common administrative VOB".
If projects in one PVOB need to modify components in other PVOBs, your Rational® ClearCase® administrator needs to identify one PVOB to serve as a common administrative VOB for the PVOBs and the component VOBs.
In Figure 1, PVOB1 and PVOB2 use PVOB3 as their administrative VOB.
Related
We selected vob names aligned with our project name ( do not confuse project name with UCM project name) so that we can easily distinguish.
But recently our project name has been changed as we merge 2 products into one.
Some people suggested to rename the vob to indicate the project name.
We tried to analyze the impacts from development and build & release perspective.
There were very little changes, here and there we had to change the path variable to indicate the latest vob name.
So we agree for renaming the vob name.
Then as Clearcase admin i had to do impact analysis.
When i asked advice from senior Clearcase admin. They listed possible impacts such as below.
symlinks across vob will be broken so they may need to repair.
It is better to clear all check out items before changing the vob name
vob will be locked to prevent users from using the old vob name while name change.
Vobs has to be unmounted and remounted
Snapshot and CCRC views may be affected , so it has to be resynchronized.
and etc.
Has any one tried vob rename in your project? Can you share the practical impacts which you have faced which will be helpful for us?
If you already tried and decided not to do it again by any means , can you advice why it is not practically advisable to do so?
Thanks in advance.
Most importantly, your UCM components won't work anymore: you cannot change their root directory (ie path within the vob, or vob itself), even though you can change their name (their "title").
And that is independent from UCM project name (the UCM project don't care about UCM rename, only the UCM Streams do)
Frankly, when face with this kind of refactoring, I:
keep everything in place, but locked and in read-only
start fresh with a new component/vob, importing the latest baseline.
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.
There are two scenarios:
- We have created a number of components each in their own vobs and realize now we prefer to keep them within a single vob
- We have created a component inside what ends up being the incorrect vob.
In both cases, the vobs are UCM vobs (CQ enabled) and have had projects, development activities delivered and baselines created, etc.
Our objective is to reorganize the components and code into the desired location.
Rational support indicates there is no method to achieve this:
Move UCM components between PVOBs
Do you have any strategies for accomplishing this while retaining the relevant information?
The simple approach would be to extract the current baseline and check that code into a new component in the correct vob as a new baseline, then obsolete the component in the old vob. Any other suggestions?
We are using Clearcase 7.0.1.1
Those reorganization processes always involve, with UCM, to duplicate the few latest baselines of those components into the new UCM destination component, and then keeping the old history.
(with CC7.0.x as well as latest CC7.1.2)
That is why I would suggest to lock the old components/streams/projects, but not to obsolete them, in order for the version trees of the old elements to still be visible (for reference).
Note that moving an element between components is possible is the "new ClearCase" called Jazz VCS, part of RTC -- Rational Team Concert --, as explained in this thread: "Team > Move in Repository" (albeit only for top level directory).
That is why the technote you reference states (for ClearCase refactoring between components):
The decision was made by Product Management to exclude the addition of this feature from future upgrades and releases due to the significant architectural changes required to implement the solution.
It will stay that way forever with ClearCase, since ClearCase has been rewritten already... but as a module of RTC.
I wish to script the following function.
accept a ClearCase stream name
list all the modifiable components associated with this stream
list all the Java projects owned by each modifiable ClearCase component
I have managed 1 and 2 above using cleartool commands.
I am now stuck as to how to list all the Java projects owned by each modifiable ClearCase component.
If it helps (or I could use this some how in the solution), the Java projects are all created in IBM Rational Application Developer, so there are one or more .project files contained in each ClearCase component.
How might I complete this task?
An UCM component is just a set of files within one common root (either a Vob itself for a "Vob component", or one of the Vob direct subdirectories).
That means once you have found the right components, all you need to do is to search for the .project files within said components.
A simple cleartool find should be enough.
How would I go about moving elements between base and a UCM VOB?
First: a base VOB can also be an UCM VOB (i.e. it can have non-UCM directories, and UCM component)
When I define a new component, I always do it in a special branch, in order to allow developers to go on and modifying version in their legacy non-UCM views, while reorganizing the directories and defining an UCM component:
Since the root directory of that UCM component is in a special branch, nobody sees anything until they define their own UCM view referencing that component.
The key factor you need to be aware of is that, once a UCM component is defined, you won't be able to move its elements outside said component:
you cannot move them within the same VOB as the one where you define your UCM component( I am speaking here of a component define within the VOB, not of a "VOB component" where the all VOB is a component!)
you cannot move them from the component to another VOB
One scenario I am aware of is the necessity too split an UCM component in two, relocating some of its code elsewhere (either in the same VOB or in another).
In that case, the only solution is to list the baseline of the source components, and clearfsimport the part you need to another directory elsewhere.
See the "clearfsimport to new stream" SO question for more on that clearfsimport process)
If you add some precisions about your current scenario, I will complete this answer with possible solutions.
Doesn't seem to be possible from Base To UCM..not in a clean way anyways