We are having 9 UCM Components. we are using some in-build tool to find code count. but we need to use baseline for each component and place it in base clearcase view with those labels in config spec. It's a complex process altogether.
I want to find consolidated code count for all the elements in the component. Is there any easy way is there in Clearcase UCM commands?
You can use a rootless component in order to define a composite baseline.
You would have one dedicated stream in which:
you would update with the relevant baselines for each component (rebase)
you would keep the rootless component with, in its dependencies all the other components
you would create a baseline each time you want to freeze the list of baselines represented by the other components of that stream.
Creating a baseline when there are many read-only component and one rootless component with create a composite baseline on said rootless component, which will include the baselines of the other root-based components.
You can then have another stream, dedicated for reading a specific (composite) baseline of that rootless component: a view on that stream will give you access to the content of all the root-based components referenced by the composite baseline.
Related
I'm trying to understand the hierarchy of UCM objects: UCM project, streams, baselines, composite baselines, VOB components, activities, change sets etc.
Can you explain the hierarchy links between these objects? Can you provide a link to a good explanation?
A visual diagram will be good as well
Thank you!
An UCM project is a container forn UCM Streams.
It contains at least one root stream (called "integration stream"), and several sub-streams.
See "Integration stream vs integration view in ClearCase" for more.
An UCM Stream is the representation of a "development effort", ie a way to share:
- what you want to do (name of the Stream)
- what you need to do it ("configuration" or list of Baselines for each Components)
A Baseline is a fixed version for a Component: all the files of a Component are labelled with the same label attached ot a Baseline.
A Component is a coherent set of file (even if you modify only one, you branch or label the all set).
You can have "component of components", which will trigger the creation of composite baselines:
See "What is composite baseline in UCM and when it will be used?" for more.
An activity is the list of versions you have modify for a given component, within a given Stream.
See "Clearcase: Activity dependencies for integration stream merging (patches)" for more.
See "How data flows in UCM projects"
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.
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.
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
We are migrating a fairly large codebase from VSS to Clearcase w\ UCM and are considering organizing our source into one or more components within a single project. What best practices\potential pitfalls should we keep in mind?
The source is organized into layers (data layer, business layer, GUI layer). The team is fairly small, developers tend to own a certain layer of the codebase and we anticipate a fair amount of branching due to parallel development efforts.
Single most dangerous pitfall:
Once a component is defined, you cannot move an element outside of this component (you can copy it and re-create it elsewhere, but you will loose its history)
Single most useful best-practice:
Understand well the nature of an UCM component: it is about coherency.
A component is a set of file which:
evolves as a single unit,
is labeled (baselined) as a whole,
is branched as a whole.
If you can make evolutions without touching another group of files, chances are you have two components.
Example of components:
an application (or a autonomous part of an application)
a technical library
a packaged set of file (for release)
The one document that should guide you to define components is the Applicative Architecture (which takes the business and functional specifications and project them onto applications which will then be specified at the technical level and implemented).
When all those components are defined, you have two approaches to manage them:
system approach (every components is writable in a UCM project): useful for starting a project, but cumbersome with legacy project: you do not need to put a baseline on each and every components simply because 3 files has changed in one of those components.
component approach: one or two writable components, the rest is there only as non-modifiable component. This is a scalable approach, allowing you to define one project per-component to develop, with a "fixed configuration" (i.e. "the other baselines", representing fixed states of the non-modifiable components you need to have in order to compile the modifiable one. You can change at any time this configuration, that is you can rebase the foundation baselines of the non-modifiable component whenever you want).
You can define as many Projects and Streams you want, allowing you to easily visualize the merge workflow.
Remember: a Stream represents a development effort.
Do not call a Stream after a resource (like VonC_stream), but after a task or set of tasks to do in that Stream (as in APP_LCH_R32_Dev: Development for 32th release of my App Launcher)
Note: UCM is just some meta-data on top of ClearCase: even if a group of file is defined as a UCM component, nothing prevents you to still making classic non-UCM branches, checkouts or checkins (in non-UCM views).
Is there a danger in creating too many fine grained components or having too many dependencies between components?
Yes, that is why Applicative Architecture is important. Again, once a component is defined, you cannot move elements between those components.
Another details to know about components is their layout:
myVob
myComponent1
myComponent2
myComponent3
A root component is always at the first level below a Vob.
You also can define a component as a all Vob but I would not recommend it (adding a Vob put stress on your Vob server. Adding a directory within an existing Vob cost nothing)
That means if you define some technical libraries as components, you cannot go as:
myLibs
Apache
ant
xalan
xerces
but will have to do:
myLibs
apapche_ant
apache_xalan
apache_xerces
Final warning: dependency (the true mark of a configuration management system)
One of the main advantage of UCM (or so I thought at the time -- 2003 --) is dependency.
If A depends on B, and I put A in my project, it will automatically include B in the same project.
Magic.
But it is broken.
First, never do root-based dependency (a root-based component is a set of file). It will break at the first overlap:
A1
B1
B2
Here you need B2 to go on building A, but A starts from A1 based on B1: B2 overrides B1. As soon as you put a baseline on A (A2), it is over. You will not be able to change B anymore. A parasite baseline (called A2!?) will have been put on the (non-modifiable!) component B because of the overlap.
Always include your dependencies in a rootless component
ADep1
A1
BDep1
B1
BDep2
B2
Here you have rootless components ADep and BDep (a rootless component is a special component which aggregates other rootless or root-based components)
You still have an override, but this time between rootless components.
That will still make a parasite baseline (on BDep, called A2), but at least you will be able to rebase BDep2 into other baselines later (BDep3, BDep4...)
More on this Incoherences and Inconsistencies of ClearCase UCM, with Rational counter-arguments here (and just after that their post, proof that their arguments are not very good to say the least).
Read also How to Leverage Clearcase’s features