Strategy to migrate from StarTeam 5 to Subversion?

Question

I need to migrate a large project from StarTeam 5 to Subversion, and I'd like to keep snapshots of (at least) 5-10 of the major releases. I've considered the following:

• Manual or scripted export/import of each snapshot. Advantages: straightforward, easy to select labeled/dated versions. Disadvantages: time-consuming, does not preserve comments.
• Polarion offers what seems to be the perfect tool in svnimporter, but it requires a .jar file from StarTeam 8.0 that is not present in StarTeam 5. Advantages: automated, complete. Disadvantages: requires upgrade to StarTeam 8.0 for one-time use.
• Migrate via some intermediate repository (e.g. StarTeam -> CVS -> Subversion). I haven't yet found any intermediary that will cooperate with StarTeam.
• Migrate only the latest source. Advantages: simple, fast, encourages developers to invent new solutions rather than repeating history. Disadvantage: encourages developers to invent new solutions rather than repeating history. :-)

I'd appreciate any experiences or suggestions you might offer. Thank you.

Answer 1

I'm struggling to migrate StarTeam 8 to SVN using the Polarion kit. I'm getting:

[main] DEBUG STProvider:80 - checkout ...relative/path/to/build.xml version:1.0 09:25:10,378

[main] INFO historyLogger:84 - EXCEPTION CAUGHT: java.lang.UnsatisfiedLinkError: com.starbase.util.NativeFileAccess.setLastModifiedAsLong(Ljava/lang/String;J)V

and the target file exists, but I suspect that it's unable to resolve the relative path. Do you know if there are properties (other than the ones in the config.properties file) that can be set to control this?

Answer 2

Regarding the comments about StarTeam versions: yes, the Polarion SVNImporter tool does need starteam80.jar, and yes, the StarTeam SDK 2005 only has a file called starteam70.jar. However I've discovered that you can cheat by copying starteam70.jar into the SVNImporter lib directory and renaming it starteam80.jar.

Answer 3

You can run a Star Team server for an evaluation period (30 days?) without requiring additional licensing from Borland - this would give you plenty of time to run a few practice runs, and give you a complete, reliable solution. Well worth the effort.

Also, don't underestimate the value of retaining your source history.

Updated Nov 6: One project that I'm involved with has used the Polarion tool to migrate a single StarTeam project into SVN. Took a little bit of work, but the end result is flawless. Well worth the time investment.

Answer 4

Having not used StarTeam I cannot speak to that -- but I think you've laid out some nice options.

1. Scripted import seems like it could be time consuming, not really get you everything, but at the same time, be a reliable way to get into svn and still preserve your release history.
2. What is the real downside of upgrading and throwing away the install after? Do you have to re-purchase the software? Is it a tedious upgrade? Barring that, it sounds like this may just be the best option.
3. I would really stay away from this option. cvs -> svn import is pretty shaky (really, it's a one-off thing, probably not that many individual people work on it enough to really care about making it perfect). Going from another SCM system to cvs, and THEN to svn sounds like a recipe for useless history data and frustration. :) I've only done it a couple of times, and really, the best part is once you're done, you're in svn and never touch cvs again.
4. This option does really suck. You lose all your history.. can no longer blame other dev's for screwing things up.. On the upside though, it will absolutely work, if all else fails.