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.
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.
I'm trying to import a full RTC repository into a ClearCase VOB. I have tried using clearfsimport but it seems like it only take the latest version of the files. Is there any way to import the code while retaining history (comments, renames etc.)
Such an import should be done component by component into a UCM components Vob, and not into a plain Base ClearCase Vob.
UCM components (and streams) map quite nicely with the RTC component and Streams, but with clearfsimport, the import process would still be:
manual (in that you would have to select each RTC baseline you want to see in order to 'clearfsimport' them)
done for baselines only (it would be too long to import all the RTC revisions)
without metadata like merges or rename
In theory, it is possible (but I haven't tested it), through one of the ClearCase-RTC connectors called "ClearCase Synchronizer".
ClearCase Synchronizer is a two-way data replication between ClearCase and Rational Team Concert source control.
You can choose a UCM stream or a ClearCase branch and set up synchronization with a stream of Rational Team Concert source control.
It leverages Jazz Team Build, and you can run the synchronization on a scheduled basis or as you request.
This will provide flexibility to enterprise customers to let subset of teams to choose SCM tools to work with, and yet manage all the latest source code by single SCM repository.
See "Using the Rational ClearCase Synchronizer and Importer".
But I don't know how well it can work (or if it works at all) with an empty UCM component on one side, and a full-history RTC component on the other.
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.
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