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

Question

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

理想情况下，想要获取所有历史信息，或者尽可能多地获取。

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

Answer 1

This看起来最好。 Polarion的业务是SVN，所以我猜他们对making as many people as possible use it有既得利益......

哦，先备份所有数据，先在测试库上等，等等。

Answer 2

我遇到了与Peter相同的问题：Polarion脚本无法继续使用大型CleraCase VOB，并且总是出现Java Heap Size内存不足错误。

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

Polarion脚本正在以这种方式工作：

1. 使用cleartool命令访问ClearCase数据
2. 使用自己的算法将这些数据转储到SVN DUMP平面文件
3. 使用svnadmin在SVN中导入转储文件

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

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

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

Answer 3

从clearcase迁移并非易事。极地主义者进口商的工作是为你提供支持，然而，大型清算仓库的历史和速度很难估计。

历史记录只会从main导入所有文件，不会考虑任何目录版本控制。问题是，如果重命名了文件，那么放入标签的文件将具有最新名称。导入器也不会迁移已删除的文件。

由于导入器无法使用您的config-specs，它将仅显示分支中已更改的文件，因为clearcase使用延迟分支，这与svns分支机制完全不同。

迁移工具不会合并合并跟踪，因为SVN仅支持1.5

Answer 4

只是另一种体验：

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

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

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

注意：我们使用UCM这一事实对出口业务有很大帮助：

• 分支清楚地标识（在它们附加的流之后）和
• 标签设置在 all 给定组件的文件上（在Base ClearCase中，标签可以设置任意数量的文件）

Answer 5

Polarion工具的最后一个版本是从2006年开始的，它只是不能用大型CC vobs工作。在我的情况下，它总是崩溃与堆溢出，甚至最大的Java堆空间是不够的。所以这对我没有好处。