I just took over a ClearCase UCM admin position recently, so any input on this post would be great.
We are currently using one VOB with one project. Say the project that we are working on is the software for a Car, CAR X.
Right now, there is one VOB, one component, and one project called 'CAR X' where everyone (maybe 12-15 developers) works on the software for the car.
In the future, we will probably need to make software for a new car, called 'CAR Y' which may be based off of the software that is used for 'CAR X' with modifications. We would like these to be somewhat separate. Should a new VOB be created or just a new component within the current VOB? If a new VOB and project is created, the files could be imported and modified from the new project, correct? Is there a downside to having one component used for each project housed in the same VOB?
This is complicated to explain, so hopefully I was able to get the idea across. If you need me to be more specific or answer any questions, please leave a comment.
Thank You!
It depends on the number of vobs you can expect to create over the next few months /years.
I prefer creating multiple components within a (generalically named) vob, rather than limiting a vob to one component (especially when this latter choice cannot be reversed)
You easily can define 100 components within a vob.
Trying to create / manage 100 vobs is almost impossible in term of ressources involved (too many processes)
If you know you only a few of those vobs to create, go ahead.
But my point remains: multiple components per vob is a model you can scale.
Related
We are trying set up a complex project and we are trying to limit the number of views and branches.
We are working in UCM ClearCase where different groups work independently then merge into a merge branch once everything clears testing.
Is it at all possible to point the config spec of our new views to several different branches?
If so is there anything that we need to think about?
Maybe someone could post an example that they have created?
An UCM view is always related to one Stream, so using one branch (if said Stream contains modifiable components)
A base ClearCase view could be configured to monitor several branches, but only one rule (the last one which can be applied for a given file version) will prevail, ie only one branch will be selected.
So it isn't possible.
Ours is a typical implementation of clearcase UCM :
I have 2 UCM projects each of which represent a release for us. proj2 being created from a stable baseline from proj1
proj1 and proj2 work in parallel and sometimes same elements in both get changed simultaneously. So files a.java lies in both projects and is being worked upon by developers at both. A weekly merge activity happens where downstream gets the latest from upstream project and merges are reconciled.This is my easy life.
As a part of restructuring code, team with proj2 has started moving elements (files mostly) to other places. When I say other places this could mean within the component or to a different component VOB. This has never happened before.
The actual problem:
When an inter-project merge happens, the destination branch version of element a.java could have been moved to a different location/folder. How do I ensure clearcase still merges it with the version coming from upstream project. Is using the cleartool move command enough for clearcase to know and merge at the right place ? For inter-VOB movements, will cleartool relocate command do the same for me. I am in a tightly controlled environment else would have created a sandbox and tested it myself.
I am banking #VonC or #Tamir :)
When I say other places this could mean within the component or to a different component VOB
Note that with UCM, you cannot move elements to another component without re-creating completely said element (new history).
-For inter-vob component refactoring:
I would rather mirror the refactoring in proj1 (in a special Stream) and then attempt an inter-project merge from that stream, rather than hoping that a merge from an old directory structure to a new refactored directory structure goes well.
For outer-vob component refactoring (new history)
A manual merge is safer in that case.
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.
One of the shops I'm working at relies on dynamic views in ClearCase. The established norm has been to create a new view for each project effort. Over time I've found that I've only needed to have one or two views concurrently active. I've taken to "reusing" a view by changing the config spec (subsequent to check-in, label, release, etc.). So far, it has worked out. Is there any long-term problem with doing that? If not, is there anyway I can re-name the view (change the view tag) to better reflect what the purpose of the view is?
For base ClearCase dynamic views, the only side-effect you can have when recycling a config spec are private files:
Those are store within the dynamic view storage, and not always removed when the config spec is reset.
You also need to make sure no files were left checked-out: they also are stored in the view storage, and once the config spec has changed, they may not be visible/reachable any more (but you should still be able to unco them through the 'find co' GUI).
You cannot rename (change the tag) of a view (dynamic or snapshot)
And, just to be complete, you cannot recycle the config spec of an UCM dynamic view (which reference a stream).
You can try to change the foundation baselines of said stream, but again, that is not always possible.
I vote for scrapping old views and creating views afresh. Besides all teh great inputs from VonC, from the disk space point of view, old views tend to get bulky over time and you soon you wont be a favorite with your sysadmins :-)
From my experience there is no log term affect for using only 2 dynamic views instead of one for each "project". If you don't need the views active concurrently its a good method, thats the beauty if dynamic views they can be updated very fast and very frequently.
For the renaming part, why rename? make a similar new dynamic view (or two) and give it a new name (view tag).