Moving RTC SCM content to another repository?
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?
Cheers!
Accepted answer
- upgrade your RTC-3.0.1.1 repository to RTC-4.0.5
- deliver from your upgraded RTC-3.0.1.1 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.
Comments
Much obliged Geoff. Upgrading 3.0.1.1 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.
Just add another step:
- create a new RTC-3.0.1.1 repository, and deliver the streams to it
- upgrade the new RTC-3.0.1.1 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.
That sounds painful but the best option yet. Thanks Geoff!
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)
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.
Cheers!
I wrote custom java code. I needed to 'copy' a project from one repository to another. and much is not accessible from the commandline.