Monthly Archives: May 2014

SCM Change Set History Replication and Migration with Rational Team Concert

Posted on by
1

Have you ever been asked to move your RTC development environment to another installation / deployment and wondered what will happen to all my existing SCM Change Set history? We know that Project Move and/or Copy has been a long requested feature on Jazz.net. So, I know I am only singling out SCM Change Set history as one of many items one would want to migrate as part of a RTC Project Move or Copy. Now, why did I have to even consider going through this?

I’m supporting an internal team that is adopting the Rational solution for Collaborative Lifecycle Management as part of their enterprise modernization effort. Some of the teams were already using RTC 3.0.1.x on an internal deployment site. But, the organization as a whole was not using a consistent set of tools which would help them achieve the benefits of collaborative lifecycle management(CLM). The organization decided to roll out CLM 4.0.6 on s separate internal deployment site and thus, begin to make use of the benefits of CLM. Teams with existing data in RTC 3.0.1.x (workitems, source control, requirements, attachments, etc) were going to need help migrating these artifacts to the new environment which is being set up with lifecycle projects. Workitem migration was accomplished using CSV files and RTC’s CSV export and import feature for CSV files. We even had an internal attachment migration utility that would help bring over the attachments of workitems which is not supported OOTB but can be done via the RTC API. So, enough background on the how I got to the SCM Change Set history migration question.

There is already an existing Jazz.net article that covers this to some extent, Flow changes cross repositories with Rational Team Concert. However, I quickly realized I didn’t need to do all of what the article discussed to accomplish my goal: Migrate change set history from one repository to another.

Procedure

The procedure I followed to complete this two phase change set history migration is as follows:

  1. Install a 3.0.1.x interim server running the default Tomcat and Derby deployment.
  2. Install a 3.0.1.x RTC eclipse client and connect to both source and target repositories.
  3. Migrate all the streams from source CCM server to target interim CCM server. Note: The fastest way to do this is to use stream to stream flow targets instead of repository workspaces. See Jazz.net library article 535 for details. I also would have liked to have tried the suggestion on how to migrate interim baselines but I ran into problem #2.
  4. Upgrade the 3.0.1.x interim server to 4.0.6
  5. Install a 4.0.6 RTC eclipse client and connect to both source and target repositories.
  6. Repeat step 3 to migrate all the streams on the interim source server to their final destination in the target server CCM project area.

Challenges

Some challenges did present themselves along the way which I will present below along with the workaround or solution.

Problem #1: Version Incompatibility of source and target servers

The first obstacle I ran into was the fact that each repository was at a different level and the article clearly mentioned that distributed SCM or what make change set replication cross repositories possible is not going to work from 3.0.1.x -> 4.0.6. See Appendix: Backwards Compatibility and Distributed SCM.

Workaround #1

Simply set up an interim server, migrate/replicate all the streams, manually, as outlined in the Jazz.net article, then upgrade the interim server to 4.0.6, and manually migrate/replicate all the streams to the target 4.0.6 server.

Problem #2 – Server to Server network connectivity

The next issue that I ran into was not being able to fully complete the replication of all the interim baselines during the first phase of the replication, 3.0.1.x to 3.0.1.x. Now, what does that have to do with server to server network connectivity? Well, RTC 3.0.1.x did not provide me much off a clue with its error logging. See workitem 315822. I proceeded to retrieve the baselines that I could which usually meant I could only retrieve the last baseline. It wasn’t until I went to complete the second phase that RTC client error logging gave me a better clue as to what was going on (with a little help from RTC SCM developers). I had a server network visibility issue. The interim server was behind a firewall and its public URI was also not known as part of the DNS of my network. Thus, the operations would fail with “unknown host” socket errors.

Workaround #2

What I was able to do may surprise you depending on how much you have read about how to properly set up the public URI of a CLM server. I was able to zip up the CLM install directory of my interim server installation and copy it to my laptop which is not behind a firewall. I then proceeded to unzip it and enter a local hosts file entry to map my IP address to the public URI hostname of the interim server.

Problem #3 – Insufficient JVM memory

When I had solved challenge #2, I proceeded with the second phase change set replication. The target server and the source server were now both at 4.0.6 level. However, when I tried to complete one of the first delivery or accepts, it would never complete. Change set replication goes through rounds to deliver the data. I followed the suggestions in the article regarding large replication sets. And still no complete delivery.

Workaround #3

A colleague suggested I increase the JVM memory of the source server. I changed the following default settings in the server.startup.bat first to 8G and then finally to 10G: -Xmx10G -Xms10G -Xmn1280M. This follows the suggestions to make the nursery 1/8 of the max and min values. Of course, I have enough memory to spare since my laptop has 16GB RAM. With these changes, the deliveries proceeded to complete.

Summary

In conclusion, it is possible to migrate SCMchange set history from a 3.0.1.x source server to a 4.0.x target server. It just takes a bit of patience and ingenuity. It is not necessary for both the servers to have a friend relationship. The only items needed are the following:

Special thanks to Ralph Schoon and Tim Feeney for their valuable suggestions.