关于从Clearcase迁移到SVN的工具的建议？

我正在寻找从ClearCase迁移到SVN的工具

理想情况下，您希望获得所有历史信息，或尽可能多地获取

增量合并将非常有益，但不是必需的。

看起来是最好的。Polarion的业务是SVN，所以我猜他们在

---

哦，在手之前备份所有数据，首先在测试存储库上执行，等等。

从clearcase迁移不是一件容易的任务。polarion导入器会为您提供支持，但是，大型clearcase存储库的历史和速度很难估计

历史记录将仅从main导入所有文件，并且不会考虑任何目录版本控制。问题是，如果重命名文件，将放置在标记中的文件具有最新名称。此外，导入程序不会迁移已删除的文件

由于导入程序不能使用您的配置规范，它将只在分支中显示更改的文件，因为clearcase使用延迟分支，这与svns分支机制完全不同

---

迁移工具不支持合并跟踪，因为SVN仅从1.5版支持合并跟踪，这只是另一种体验：

我们使用“自定义脚本”而不是Polarion工具。
这样，我们可以：

• 使用动态视图（快速更新）
• 准确选择要导入的分支
• 只导入带有标签的版本（避免导入大量版本，而没有人会真正利用这一巨大的历史）
• 导入上一个标签和最新标签之间的所有版本（对于给定分支）

我们使用动态视图更改其配置规范，并将所有我们感兴趣的标签导入到SVN

注意：我们使用UCM这一事实对导出操作有很大帮助：

• 明确标识分支（在其连接的流之后），以及
• 标签设置在给定组件的所有文件上（在基本ClearCase中，标签可以设置为任意数量的文件）

---

Polarion工具的最后一个版本是2006年的，它无法处理大型CC VOB。在我的例子中，它总是随着堆溢出而崩溃，即使是最大的java堆空间也不足以实现它。因此，这对我没有好处。

我遇到了与Peter相同的问题：Polarion脚本无法继续处理大型CleraCase VOB，并且总是以Java堆大小内存不足错误告终

我还遇到了另一个导致导入后数据损坏的关键问题

Polarion脚本就是这样工作的：

使用cleartool命令访问ClearCase数据

使用自己的算法将这些数据转储到SVN转储平面文件中

使用svnadmin在SVN中导入转储文件

我设法在一个较小的VOB上运行Polarion脚本。一切看起来都不错（导入成功完成，没有错误消息），但SVN存储库不可用（无法检出，没有确切的错误消息）-尝试了几次，结果相同

我知道脚本是基于自己的代码而不是任何SVNAPI重建SVN转储文件。它可能是为SVN的一个特定版本设计的（1.4，可能是1.5？），而我使用的是SVN1.6。转储文件格式可能已经更改，或者Polarion脚本无法正确处理特定ClearCase数据的一些副作用。然而，在一天结束时，它只是不起作用

---

因此，我强烈建议使用另一种解决方案，并可能基于cleartool和实际的SVN API构建您自己的脚本，以避免任何数据一致性问题。

感谢您对可能出现的问题的进一步了解。但是好处大于数据的损失。svn转储文件格式应该是版本无关的。现在是