Starteam到SVN的迁移，Polarion的替代方案？

Question

有没有人知道替代Polarion将Starteam (2006v2)迁移到SVN的方法？仅我们的源代码就有10 is，不包括所有的修订历史。每当我运行Polarion svnimporter时，我都会得到一个"Java out of memory“异常。我不确定是什么导致了所有的内存使用，但我也不确定从哪里开始。任何建议(至少允许我保留一些历史)都将非常感谢。

谢谢!

Answer 1

大约十年前，我们进行了从StarTeam到ClearCase的迁移。我受雇写一个程序来做迁移。不幸的是，StarTeam的命令行界面极其有限，并且没有真正的应用程序接口。几乎所有的StarTeam命令都必须以50个字符的登录字符串作为前缀。也许在过去的十年里，这种情况发生了变化。

您是否尝试过增加Java的内存分配？默认情况下，JVM将仅使用64Mb内存。许多Java应用程序需要更多的东西。在Java命令中，您可以给它类似于-Xmx256m这样的东西，以给它256MB的内存。我看到Polarion的软件是基于Java的，但我最终没有下载它，因为他们想要我的名字和电子邮件地址。(这根本不值得这么麻烦。)但是，我认为有一个批处理脚本或shell脚本来执行程序。

一次只能执行一个或两个目录/模块吗？许多站点使用多个Subversion存储库--每个模块一个，而不是所有模块都有一个庞大的存储库。此外，如果你真的想要的话，你可以将所有的Subversion仓库转储和加载到一个大仓库中。多一点体力，但如果它起作用，你可以保留你的全部历史记录。

我们最终所做的只是为历史转换几个标记点，而不是所有的点。我们的理论是，如果你真的需要详细的历史记录，你可以回到StarTeam存储库。

所发生的事情改变了我对这些东西的看法:事实是，我们无论如何都不能构建太多旧的东西，因为它依赖于它在StarTeam中的方式，所以即使我们保留历史，它对我们也没有太多好处。而且，这也让我们有机会重组一切，抛弃过时的东西--如果我们真的能保留历史，我们可能就不会这么做了。

最后，没有人错过了历史。StarTeam存储库使用SQLServer来维护存储库数据库。该数据库在转换后不久就崩溃了。直到将近一年后，我们才发现这件事。我只是想看看StarTeam是否还在工作，然后发现了这个问题。

因此，看看增加Java进程的内存是否有帮助，或者看看是否可以逐段地进行转换。如果这没有帮助，你可能会问自己是否真的需要历史记录，或者如果你只做几个标记点和活动分支的提示，是否可以。

如果有人真的需要历史，可以回到旧的StarTeam系统。

我希望我能给你更多的帮助，但我自己在StarTeam上的运气不是很好。

回复

StarTeam命令行界面有那么糟糕吗？应该可以编写一个简单的脚本来列出修订，然后将它们从starteam签出，然后在一个大循环或其他什么地方将它们签出到SVN，不是吗？

你会这么想的。毕竟，我已经设法为ClearCase、CVS、Subversion等编写了自己的转换例程。然而，当我十年前这样做的时候，Borland的CLI很糟糕，文档也很糟糕，Borland(拥有StarTeam的公司)根本帮不上忙。

命令行工具没有登录。每个命令都必须提供凭据，这意味着在每个命令中输入大约50个字符串。这也意味着CLI对您实际查看的内容一无所知。您不能执行svn info like命令。你只是检查了一堆东西。

没有办法通过命令行查看详细的历史记录。例如，没有办法找出所有的修订，并像使用Subversion甚至CVS那样一次一个地检查它们。

有一个C API，但它也是相当有限的。我看到现在有一个Java API，这可能就是Polarion正在使用的。

我在想也许有一个StarTeam to CVS软件包，它可能会对事情有所帮助。在您转换为CVS之后，您可以将其转换为Subversion。遗憾的是，除了在互联网世界的黑暗中有几个人在问同样的问题外，我什么也找不到。

我尝试下载API信息或命令行文档，看看是否能弄清楚什么，但网站宕机了。

对不起，我不能帮你，只能说我试过了，但失败了。

Answer 2

我正在将一个中型项目从StarTeam迁移到Subversion。我也不得不处理许多由于VM内存不足而导致的JVM崩溃。似乎Polarion库/工具或他们从StarTeam使用的StarTeam.jar文件有大量的内存泄漏。在任何情况下，通过执行以下操作，我似乎已经克服了这一点(祈祷)：

java -Xmx2048m -cp svnimporter.jar:starteam80.jar org.polarion.svnimporter.main.Main full config.properties

现在它已经在大约11000个文件上运行了大约3天。并且只完成了一半..所以至少可以说这是一个缓慢的过程。

我找不到其他的工具...所以祝你好运。

Answer 3

我不知道starteam，但通常你可以导出一个标签/标签列表(或者所有标签？)从您的源代码版本控制系统。然后使用svn_load_dirs.pl将它们“堆叠”在一起。

这意味着你不会有完整的历史，但至少你的大部分冻结的项目状态。

您可能也可能不会导出一些带时间戳的版本，并尝试将它们堆叠起来。

我最近迁移了一些简单的clearcase VOB，只检查签入/提交历史，并为每次签入导出项目的完整版本，并使用svn_load_dirs.pl将它们导入到新的svn存储库中。