It's all about the answers!

Ask a question

How to export/import source code history from one RTC instance to another ?

Udaya Puthuraya (8811421) | asked Jun 25 '13, 6:55 p.m.
Is  there any  guidelines  or articles on  exporting source code from one RTC instance  to another RTC  instance.

We have 2 existing  project areas in 2  RTC instances  residing in  2 different physical consoles and databases.
Now  one of the  product team  has decided to  move it's project area assets(source code, streams,components,snapshots, work items with all the history) and merge with  other product  that is hosted on another RTC instance.   Ideally they want to use 1 project area with out loosing  any history for the  proejct area that is being migrated. 

Work items generally can be exported in CSV  format and  imported to the 2nd project area using RTC eclipse client export and import feature.

What is the option provided by Rational  to do the same for  source code history migration  from one RTC instance to another  ?
Is there any export import feature for change set  history in Eclipse client ? ( Under Import option, Jazz source control -> Change Set Archive)

By enabling  distributed SCM  on both the servers,   with a small test,  loading the work space from the source stream and changing it's flow target  to a empty stream created in the target instance, we were able to move the history to some extent.
History of the component  in the target stream,  in the  target instance showed change sets with  associated work item numbers from the source RTC instance. Obviously these associated work item numbers  does not exist in  the target instance.   Is there better way to keep this change set links to associated work items,   to the right work item numbers in the target instance  ?
or any  better approach for this migration scenario ?

2 answers

permanent link
Geoffrey Clemm (30.1k33035) | answered Jun 25 '13, 11:53 p.m.
Using distributed SCM is the best approach I know of.   I'm not aware of any built-in way to adjust the work item links to point to the replicated work items in the new server, but you should be able to use the SCM API to write a program that scans all the replicated change sets, and changes their work item pointers from the work items in the old repository to the corresponding work item in the new repository (assuming as part of the work item import process, you have some work item field that contains the old identifier for that work item).   There should be folks on this forum that can give you guidance on the API calls that you would need to use in that program (but unfortunately, I'm not one of them :-).

For details on using the RTC distributed SCM capability (especially for large histories), see:

Udaya Puthuraya commented Jun 26 '13, 10:42 p.m.

Thank you for quick response  confirming our approach  and the pointers on API.
Looking forward  for  guidance on  API calls from the experts.

I was also thinking  on the same approach for change set link  fixing.   But not with API.
Thought  scm/lscm  command line may have some command to get the current work item association  for change set  and  a command to  update it as well.
If that was true, When we export/import the work item, Have a new attribute in the work item that will  store the  old work item #  in the new RTC instance.
Then extract this info. (New work item #  and Old work item #   from the target RTC instance after the work item migration)  in  csv/text file form  and
use some command line scripting  with this input file,  to update the associated work item in the change set.

permanent link
nishant Vartak (11) | answered Nov 13 '13, 12:18 a.m.
Even I have to perform this exercise. Where you finally able to find a solution which could transfer changesets and workItems history seamlessly into target repository? We have RTC 3.x at our end.

Udaya Puthuraya commented Nov 15 '13, 11:26 p.m.

We ended up not bringing the history(no change sets and associated work items), only snapshot of the latest code stream.
If you want to bring the history with change sets and associated work items, you could setup distributed SCM  as in   and use duplicate stream feature.  (Duplicate a stream from source repository to target repository  and rename it)
This will also bring the history. But work items are linked to the original(source) repository. Duplicate stream is executed from repository to repository without using local work space and is quicker.

Your answer

Register or to post your answer.

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.