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
Related
Currently we use ClearCase UCM.. I am trying to evaluate possibility of using git in our project. I decided to create large repo with past three years changes from an integration stream. The pvob has 12 vobs under it. For purpose of evaluation(creating a worst case), I am putting all changes into single repository.
I want to create a base clearcase view and then adjust its spec for every baseline on the pvob. This will then synched to git repository.
Question in short: How can I create a base clearcase view given a pvob base line and keep changing its config spec to match every baseline?
(academic note : A picture of what I am trying to achieve.. )
(Approach discussed in ClearCase UCM: Is it possible to have a temporary view on any given baseline? is kind of work around in my case. I guess I can avoid the step of creating many temporary streams- not sure how!)
I am putting all changes into single repository.
This isn't the right granularity for a git repo.
Having done multiple ClearCase to Git migration, the right scale usually is one UCM component equals one Git repo.
How can I create a base clearcase view given a pvob base line and keep changing its config spec to match every baseline?
You don't have to create a base ClearCase view.
You can create a sub-stream to the Int stream, and manage the baselines you want to see there.
(cleartool rebase -bas xxx#\YourPVob)
You can then use an UCM view to that sub-stream as a source for your git import.
If that approach isn't possible (as I explained in my previous answer you mention, because for instance all baselines haven't been created in the same parent stream), then you can create a base ClearCase view and modify its config spec in order to select the baseline complete ids:
element * BaselineId1
element * BaselineId2
...
(A dynamic view here is more useful to tweak the config spec.
Once the config spec is set, you can update a snapshot view with the same config spec, and appropriate load rules, to use it as a source for your git import).
You need to make sure those baselines are:
full baselines (you can promote an incremental one to a full one)
referenced with their id (not their title, which is their visible name).
See also "Display Current Baseline with Cleartool":
cleartool describe -l baseline:aBaseline#\aPVob
cleartool descr -fmt "%[found_bls]CXp" stream:myStream#\myPVob
The second command would give you all baselines in a stream.
In both cases, you would see the baseline ids in addition of their names.
I have mention the ClearCase to Git migration aspect in :
"Migration from UCM ClearCase to GIT"
"How to integrate ClearCase development history into Git?"
"Save history from ClearCase to Git?"
"How to bridge git to ClearCase?"
"Sync GIT and ClearCase"
A good trick is to use:
git --git-dir=/path/to/git/repo/.git --work-tree=/path/to/ClearCase/view add .
That allows you to consider the ClearCase view as the working tree of your git repo (which is the destination of your import).
I generally don't try to import all baselines from all streams because it is too complex too soon (in order to get the sequence of those histories right).
I just get a few baselines from the main stream, import them and go from there (keeping the ClearCase referential as a read-only archive source for history research).
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.
I was told to create component in UCM.
How would you explain a difference between component and VOB to a beginner?
Also It asks two option.
Components in VOB and Components without VOB.
What is the use of having Component without VOB?
You always have a Vob involved with a Component.
A Vob is the database (file-based database, not an SQL-based) containing all versions of all elements (files and directories).
Not to be mixed with a PVob, which is a special kind of Vob containing only UCM metadata (like the list of UCM projects, streams, components names, activities, ...).
You have two kinds of components, but each one is a coherent set of files:
Vob component: the all Vob is a component.
Root-based components: the component has its root in the first directory level of a Vob: \aVob\aRoot.
It is best to create root-based components (ie, several components per Vob), because each Vob you would create means several processes to manage it (vob_server, vob_rpc), and it becomes quite resource intensive quickly.
However, several components (even an hundred) within a Vob is not a problem.
But that means the name of your Vob must be "generic" enough to accommodate your components.
As for rootless components (with a PVob, but no Vob), see "About rooted and rootless ClearCase UCM components".
Rootless Components:
should NEVER be modifiable in a UCM environment.
are not associated with a data storage (vob-less)
are used to track changes from Other Components.
can contain dependency lists also known as a (Composite baseline Structure)
are tracked with baselines that have NO corresponding label type.
Rootless Components should only be used to track the progress of Rooted Components.
Rootless component baselines should be used when rooted component dependencies are needed. The dependencies are rigid and can enforce a strict process once implemented.
See "To create a composite baseline" to see a rootless component in action.
I don't think the question is answered. VonC described two types of VOBs can be created, a single component VOB and multi-component VOB, to store the files. The question however is asking what's the use of creating a component w/o a VOB, one of the options when you create a component.
This type of rootless components are normally used to store the composite baseline. I am not aware of other usages.
I found this post because today I got an issue with my IIB projects. When loading dependency projects from another component, IIB toolkit will complain the dependency project is not from the same root directory (due to from different components in CC). This is really an IIB toolkit issue, but I am looking for a way to resolve this from CC.
This is a follow up question to this answer: https://stackoverflow.com/a/9579131/1204799
"It is best to create root-based components"
If I have several standalone applications (which means their development and deployment are independent), shouldn't I create different VOB to accommodate them? What I'm doing now is that, I have one single PVob, which contains a few UCM projects, each UCM project has its own Vob and baseline component(a component without Vob). Am I doing it the wrong way?
Updated at Mar-7 16:29
After taking your advice, this is what I am trying to do now:
I created a single PVOB to accomodate all the VOBs
I created one VOB for each business team, which, in my company, only three teams
I created one UCM project for each application. Each business team
will host several applications, each application is rather
independent, but every application may have more than one branch for
parallel development, so there can be a lot of projects
Here comes my question:
Now several applications are sharing the same VOB, how can I better manage the baselines so that they are organized by applications? i.e. to prevent accidentally choosing baselines of another project
It is best to use multiple components within a (generically) named Vob.
Making a component per Vob is not "wrong" per say, but you need to know that, once a component has been assigned a root directory (like a Vob), you can no longer change that root, or make any refactoring.
By "refactoring", I allude to the classic case where I create a component "MyProject" (with its Vob '\MyProject'... before realizing, for example, a few months later that 'MyProject' has actually a server and a client modules which could benefit from a separate history: I should have defined two components and not one.
With the "one vob per component" model, I have no other choice that to create another Vob: I cannot refactor, ie I cannot make a subdirectory within my existing component, and define a second component there.
With the "multiple components per Vob", I can:
rename my first component as "MyProject_Server", with its root directory '\MyVob\myproject' (which remains unchanged: you cannot change the root directory of a component once created),
make another component within the same Vob: "MyProject_Client", with a root directory '\MyVob\myproject_client'.
The main advantage is about scale: you can define many (hundreds) components within a Vob.
But you shouldn't define hundreds Vobs, because of the sheer number of processes (vobrpc_server and vob_server) required to manage the access to said Vobs.
If you create several components per Vob, that won't have any influence on the baseline choice for each project UCM.
Ie you would have as much risk of choosing the baseline of the wrong component, whether those components are a full Vob or are part of a Vob.
You would simply separate those components in different UCM projects, and manage each component baselines in those UCM projects.
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.