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.
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).
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'm attempting to import a clearcase project into rtc source control and I'm following this tutorial :
https://jazz.net/library/article/50
Is this tutorial sufficient ? When code is checked into clearcase will it also be checked into rtc source control automatically?
Any common pitfalls / online tutorials welcome
Honestly, for a couple of baselines, I simply create an import RTC stream (ie, a stream dedicated for imports), and I manually copy a few baselines, selected from a dynamic view (which has a config spec you can easily change in order to select the appropriate baseline)
Whatever the tool you end up using for this import, the common pitfalls are:
import directly in an RTC Stream used for development: it is best to isolate the import in a dedicated Stream, which will allow you to start working on one of the imported baselines in an RTC Dev Stream, while completing further round of import later in time in the Import Stream.
import all the history (instead of only a few selected baselines)
import without cleaning first (ie you might realize you stored in ClearCase quite a few binaries, libraries or other generated files that you might want to ignore, through a .jazzignore file for the import)
import without refactoring the components: a UCM ClearCase component might have been use over the year as one giant bucket for multiple projects codebases.
The import to another VCS is the good time to split it into several smaller components.
Shutting down ClearCase completely after the import: since you don't import all the history and not all the owner for each versions, you might need to consult back from time to time the history stored in ClearCase.
Don't forget to lock the vobs though, to ensure a read-only access.
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 Can I Revert to Earlier baseline? We have a UCM parallel development(multi-stream) project. Each developer have a snapshot view on Project's Integration stream.
Developers want to see earlier version of the application in their snapshot views so They can debug early version of application to find bugs.
When I want to change an existing snapshot views's foundition baselines, clearcase does not allow me. So How Can I do this?
Since you employ the term Baseline, I will assume you are using UCM.
On a stream, you can not revert backward a baseline.
One possibility is to make a parallel stream, with the desired baseline as foundation: this is the quickest way.
After changes on this new stream, you can make a new rebase to change the foundation baseline, but only if that new rebase is using a more recent baseline from the parent stream (not an older baseline)
For your specific need, I would recommand a non-UCM snapshot view with a simple rule
element * thePreviousBaseline
In order for the developer to have:
his/her current UCM view for development (always set on the LATEST of a branch associated to a stream)
a second snasphot view set to whatever baseline he/she needs.
That second snapshot view is completely not-related to the UCM project and takes advantage of the "full" nature of the baseline (do check that your baseline has been put as "full", not "incremental". If it is "incremental", simply change its type and upgrade it to full)
So, beside your current snapshot UCM view, you can create anywhere you want a non-snasphot view:
cleartool mkview -snap -tag mylogin_myComponentname_csl_snap -vws myPathToViewStorage myPathToRootView
cd myPathToRootView
cleartool edcs
[add the selection rule: element * myOlderBaseline]
[add the load rule at the end: 'load /myVob_Including_MyComponent]
[save, type 'yes']
That is fine for consultation/execution, but if you need to patch (that i is to write, check out and in some files), then I would recommend one UCM stream per baseline to be patched.
That way, the stream clearly represents the patch effort for a given baseline. There should not be too many of them, unless you put into production a new version of your application every five minutes... which is not advisable ;)
So to summarize:
the non-UCM snapshot view is unique and serve for a quick consultation/debug of one older baseline at a time.
for patches (source modification), you create a parallel stream properly named, with the correct foundation baseline, and then a UCM view on it. You can not only debug but also fix some bugs in an activity, the deliver that activity to the main Int stream if that bug need to be retro-fitted on an higher stream.
(note: all bugs do not always need to be delivered: they can be obsolete when compared with the current state of the development)
The way I have solved this problem is by making another Stream, a child Stream of the Integration Stream. The easiest way to create this Stream is to open ClearCase Project Explorer (not Rational ClearCase Explorer) and navigate to the Project and then the Stream in question. Right click on the Integration Stream and select "Create Child Stream..."
Click "Advanced Options" and select a baseline for each component. Do this by selecting the component and then selecting "Change..." and selecting the specific baseline you want to see. You probably want to select "Prompt me to create a View for this Stream." Select "OK".
Any developer can do this. You don't need to be a VOB owner or Project or Stream owner.
Well, it depends. Actually, the answer lies in setting up your config spec to point to the proper files. Your config spec tells your view which versions of elements to look at. But how you do write it depends on your project's approach to baselines. Did you apply a label to mark that baseline? If so, and if you only want to read and not checkout anything new, your config spec can be as simple as
element * <LABELNAME>
If you didn't use labels, you can also set up your config spec to show you files based on dates. It gets more complicated the more rules you need to add to constrain your element choices. If you have more specifics, I can try to elaborate on what rules you might need. Otherwise, I would read the manuals that come with ClearCase. If you view the Extended Help from ClearCase Explorer, and then do "Viewing Rational ClearCase Manuals On-Line" it should give you some links to the Command References. This is where I go whenever I need to modify my config spec in some new way.
Also, note that we only use dynamic views, so I don't know if snapshot views work differently.