It's all about the answers!

Ask a question

Moving RTC SCM content to another repository?

Bryan Miller - Integration Developer (4493531) | asked Feb 04 '14, 6:16 p.m.
I have a need to move code under Jazz SCM from one repository to another and wondering if there is a good method of doing so.  My source is RTC and the destination is RTC 4.0.5.

I have figured out how to move work items but the code has me thinking.  I would like to try temporarily "friending" the new repository and attempting a deliver to the new project(s).  Has anyone tried that approach?  Is there any other approach that would allow me to preserve my baselines and snapshots?


Accepted answer

permanent link
Geoffrey Clemm (30.1k23035) | answered Feb 04 '14, 6:35 p.m.
To replicate code from one RTC repository to another, you would use the distributed delivery (see   But it is likely that you will not be able to do so directly from an RTC- repository to an RTC-4.0.5 repository, so you would have to do it in two stages:
- upgrade your RTC- repository to RTC-4.0.5
- deliver from your upgraded RTC- repository to your RTC-4.0.5 repository

In order to replicate your baselines, you will need to deliver each baseline individually (clearly, scripting this up will be in order, unless you are very patient).   Also, there is no way to automatically replicate snapshots, so you will have to recreate them in the target repository.

Bryan Miller - Integration Developer selected this answer as the correct answer

Bryan Miller - Integration Developer commented Feb 04 '14, 6:40 p.m.

Much obliged Geoff.  Upgrading to 4.0.5 is not an option - which is part of the reason for the move.  Is dumping to a changeset archive an option?

Scripting up the baseline delivery should be straightforward.  I'll do a query to see how many snapshots there are in the source repo to get a feel for the complexity of the move.

Geoffrey Clemm commented Feb 04 '14, 6:49 p.m.

Just add another step:
- create a new RTC- repository, and deliver the streams to it
- upgrade the new RTC- repository to be a 4.0.5 repository
- deliver from the new 4.0.5 repository to the original 4.0.5 repository

Note: There is no "changeset archive" function.

Bryan Miller - Integration Developer commented Feb 04 '14, 6:56 p.m.

That sounds painful but the best option yet.  Thanks Geoff!

sam detweiler commented Feb 04 '14, 7:51 p.m. | edited Feb 04 '14, 7:56 p.m.

we just went thru this process.  it is very painful.  but u can use distributed SCM to do the data movement (same version restrictions)

I wrote tools to do the migration of all the project  components, and source.
(and collapse 3 project areas into one). a colleague wrote the link fixup tool.

relative transfer speeds between two 3.0.1 repositories was 10-12 minutes per workspace (5-6 meg). 20 hours.. upgrade middle man to 4.0.4, then jump from 4.0.4 to 4.0.4 was blazing.. 1 hour total. i added a lot of filtering lately to try to reduce the number of streams and workspaces transported.
we had a sequencing problem on the 1st pass, where the parent streams had not been relocated, so all the workspaces lost their flow targets.. ugly..

I think we have 3 more of these to do.

if I have any say about it, we will use strategy 1 next time: upgrade a copy to 4.0.4,  and copy stuff only once.  but due to the repository url requirements force the source system to be offline during the work. (and u have to make the upgraded 4.0.4 copy read only too)

Bryan Miller - Integration Developer commented Feb 05 '14, 10:20 a.m.

Thank you Sam.  That is very helpful.  Did you use wrapped CLM command lines or full-on Java API?

I, too, am concerned about things like stream targets, baselines, etc.  I'm hoping to have a go at it this weekend.  I'll post my success, or lack thereof, here.


sam detweiler commented Feb 05 '14, 11:28 a.m. | edited Feb 05 '14, 11:31 a.m.

I wrote custom java code. I needed to 'copy' a project from one repository to another. and much is not accessible from the commandline.

streams and workspaces were the next to the last component. 
builds & defs need the workspaces to exist first. 

Public URI was the issue I was mentioning in the last paragraph above. 

showing 5 of 6 show 1 more comments

Your answer

Register or to post your answer.