What are the advantages & disadvantages of using Rational ClearCase Bridge versus Rational ClearCase Version Importer?
We are trying to determine whether to migrate our (large) codebase from our existing UCM repository into RTC using ClearCase Version Importer, or to integrate with it using ClearCase Bridge.
What are the advantages & disadvantages of using Rational ClearCase Bridge versus Rational ClearCase Version Importer?
If we decide to use a Bridge, what functionality/features of RTC will not be available to us?
Thanks for your help!
2 answers
Comments
Thanks Geoffrey!
Are there any features of RTC/Jazz that will be unavailable to us if we continue to use UCM for source control?
For example, will it be possible to start Jazz Team Builds from within RTC if our source is in UCM?
There is no technical limitation that makes any RTC features unavailable while you use ClearCase Bridge, as far as I know. You can use Jazz Team Build while you continue to use ClearCase UCM. This video may help you:
http://www.youtube.com/watch?v=TPnAUzdBZxc
In terms of Version Importer, I DO recommend to use Version Importer for UCM as well because the Baseline Importer does not import any UCM metadata either. You can specify an option of the Version Importer to essentially do the same as what you can do by the Baseline Importer.
Thanks Masabumi!
I believe that RTC allows administrators to finely control what actions a user can perform via SCM, for example, what streams a user can flow their changes to.
Is such fine grained control possible only for code using the Jazz SCM?
Oh, if you compare ClearCase and RTC SCM, you'd find many differences. You may find a summary of the change in one slide of the enablement session recording:
Webinar: Importing Version History to RTC
Ah yes, I see on slide 4 that Process Integration is specific to RTC SCM.
On slide 11, it infers that ClearCase is preferable to RTC SCM for 'Very large development projects'. I realise it is difficult to give a single figure - above what approximate size would it be better to use a Bridge rather than importing the UCM project into RTC?
There's no simple answer for you about large deployments because it really depends on your CC or RTC deployments ( machines, network topology, database, etc.). I'd say CC and RTC has different approach to scale to large deployment, and CC has longer history of supporting large deployments successfully.
Like Georg mentions below, the bridge is a way to use RTC in a complimentary fashion, and easy to deploy for existing CC deployments. If the user community is happy with CC, there'd be no reason to 'force' them to switch SCM from CC to RTC.
If you're more interested in consolidating servers to single solution ( as opposed to deploy/maintain both CC and RTC), and developers are not using CC's unique capability, migration to RTC can be an option for you but it requires more planning/execution work than the bridge.
1 vote
configuring the bridge is easily done (I would say an hour the first time, every additional project/component will take minutes), while doing a migration from one SCM system to an other can take weeks, based on the repository size, team size, complexity of development environment and so on.
So what is the goal?
If it is the integration (UCM) ChangeSet - RTC task, the bridge would be the solution.
If you have problems with CC UCM, which can be solved with RTC SCM (I remember some refactoring issues in CC), a migration can make sense.
Regarding size of a project in UCM:
In UCM you can use rootless components containing rooted components, and also rootless components, based on rootless components.
I know projects having:
rootless "system" component containing
rootless "sub-system" component containing
rootless "component" component containing
rooted "module" component
Such combinations are not possible in RTC afaik.
greetings georg.