ClearCase 到 SVN 迁移
好吧，我在使用 SVN 导入器工具来迁移具有悠久历史的 ClearCase VOB 之一时遇到了问题。我们想到通过选取 10 -15 个基线版本的代码并将其导入到 SVN 来实现此目的。 因此，为了做到这一点，我认为用户必须一一给我具体的版本。 所以现在他问我如何在clearcase中指向特定版本并将其导出？ .这里的想法是将代码作为 tar 球提供给我...这样我就可以在桌面上分解它并将其导入到 SVN。 ....!!!! 我不知道如何在 SVN 中导入/分层所有这些基线......这与 SVN 类似吗？ 你能帮我解决这个问题吗？
Well I have an issue with SVN importer tool for migrating one of the ClearCase VOB which has a huge history ..we thought of doing this by picking up like 10 -15 baseline versions of the code and import it to SVN. So for doing that I think the user has to give me the specific versions one by one . So now he is asking me how to point a specific version in clearcase and export it ?? .The idea here is to give me the code as tar ball ...so that I can explode it on my desktop and import it then to SVN. ....!!!! I Don know how to import / layer in all this baselines in SVN.......Is that something similar to SVN. Can you please help me with this.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
另一个选择是 Migrate2SVN。 开发商 (Clearvision) 刚刚发布了 v2.0，它似乎包含了对 Polarion 软件和上述其他方法的许多改进。
http://www.clearvision-cm.com/clearcase-subversion-migration.html
希望这对所有与我登陆同一页面的 Google 用户有所帮助:-)
Another option is Migrate2SVN. The developer (Clearvision) has just released v2.0 and it appears to include many, MANY improvements over the Polarion software and other methods mention above.
http://www.clearvision-cm.com/clearcase-subversion-migration.html
Hope that helps any Google'rs that landed on the same page as me :-)
我没有使用过它，但我听说 SVNImporter 会导入您的 ClearCase VOBS，包括历史记录。
听起来您的用户真正要求的是一次从 CC 导出几个版本，以基本上“折叠”现有历史记录。 举例来说，您有一个包含数千个修订版本和数百个标签的大型 VOB，并且您希望仅将最后 5 个主要版本作为新 Subversion 存储库中的历史记录。 您可以从 CC 导出所需的最早版本，导入到 SVN 并创建工作副本。 然后，您可以从 CC 导出一些更高版本并复制到您的工作副本中并进行更新。 起泡沫，冲洗，重复，直到获得 CC 的最新信息。
您从 CC 获得的版本由视图配置规范控制。 要仅获取与特定标签关联的文件（希望它们有标签...），请将配置规范更改为：
要获取与标签关联的版本以及与您使用的标签无关的任何内容的当前版本：
有关更多信息请参阅 IBM/Rational config_spec 文档。
I have not used it, but I have heard that SVNImporter will import your ClearCase VOBS including the history.
It sounds like what your user is really asking for is to export a few versions at a time from CC to basically 'colapse' the existing history. Say for example that you have a large VOB with thousands of revisions and hundreds of labels, and you want to have only the last 5 major releases as your history in the new subversion repository. You could export the earliest desired version from CC, import into SVN and create a working copy. Then you would export some later version from CC and copy into your working copy and do an update. Lather, rinse, repeat until you get to LATEST from CC.
The version you would get from CC is controlled by the views config spec. To get only files associated with a particular label (hopefully they have labels...) you change the config spec to:
To get the versions associate with a label AND the current version of anything not associated with that label you use:
For more information see the IBM/Rational config_spec documentation.
我自己做了一些clearcase迁移：
以下是我的想法：
不要不要使用 Gary Ray 建议的导入器，因为它还不是很成熟。 它缺少许多您想要的功能，例如目录版本控制、旧文件名的正确标签、已删除文件的历史记录等。此导入器仅适用于您真正需要内容 您的文件，并且可能会丢失整体结构更改
创建要导出的标签列表
编写脚本为标签列表中的每个标签生成clearcase配置规范
替代方案：为每个标签创建一个配置规范列表，如果您在步骤 3 中无法成功
tar 并压缩您的 Clearcase 视图并复制将其收集到您的 SVN 计算机上
将每个zip提取到一个文件夹
使用
svn_load_dirs.pl导入到 SVN，您可能还想在 SVN 中创建一个标签注意，这也适用于多个项目。 但是，如果您有共享模块（SVN 的弱点之一），您将需要特定的存储库结构，并且导入 SVN 可能会更复杂（可能使用 svn:externals）。
你确实应该自动化这个过程，因为大多数时候你会导入多次，因为你的配置规范缺少文件，你的 SVN 结构会改变，等等。所以编写解决方案脚本并自动运行所有内容，这会更多灵活直到所有迁移结束。 您可能还需要查看迁移结果。
I did some clearcase migration by myself:
here are my thoughts:
Do NOT use the importer suggested by Gary Ray, as it is not very mature. It lacks a lot of features you want to have, for example directory versioning, correct tags with old filenames, history of deleted files, etc.. This importer is only for small scale migrations where your really need the contents of your files and can loose the overall structural changes
create a list of tags you want to export
write a script to generate the clearcase config-spec for each tag in your tag list
alternative: create a list of config-specs for each tag, if you cannot succeed in step 3
tar and zip your clearcase view and copy collect it on your SVN machine
extract each zip to a folder
use
svn_load_dirs.plfor importing into SVN, you may also want to create a tag in SVNNote, that this will also work with multiple projects. However if you have shared modules(one of weak points in SVN) you will need a specific repo-structure and import into SVN can be more complex(maybe use svn:externals).
You really should automate the process, as most of the time you will import more than once, because your config-specs are missing files, your SVN structure will change, etc. So script the solution and run everything automatically, which will be much more flexible until all migration is over. You may also need to review the migration result.
注意：如果“基线”指的是“UCM 基线”，则对于给定组件（Vob 中的文件树）来说，这会变得更简单。
创建一个具有单个集成流及其动态视图的 UCM 项目，然后：
将为您提供要导出的基线列表。
在动态视图中会将视图设置为导出源。
（对每个基线重复此操作，将最旧的基线导入到最新的基线）
但是，如果您使用的是用 base-ClearCase（而不是 UCM）标记的数据，请注意此问题：
可以将 base-ClearCase 标签放在任何文件。 像 Gary 建议的规则
很可能最终选择 0 个文件，仅仅是因为标签“
DESIRED_LABEL”尚未放在根目录“MyPath”上！另外，没有“时间线”修订的概念（如 Subversion 中的修订）。
如果标签被证明太不可靠（因为没有放在所有文件上），解决方案可能是将标签的日期与基于时间的规则。
“
date_Of_The_Label_Put”是在至少一个元素上应用标签的日期。如果某些元素没有被标记，它们仍然会在正确的版本中被选择，即标签被部分应用到一组文件时的版本。
Note: if by "baseline" you are referring to "UCM Baseline", this becomes simpler for a given component (tree of files within a Vob).
Create a UCM project with a single Integration Stream and a dynamic view on it, then:
will give you the list of baselines to export.
within the dynamic view will set the view as a source for your export.
(Repeat for each baselines, for the oldest you want to import to the most recent)
But if you are with data labeled with base-ClearCase (and not UCM), be aware of this issue:
a base-ClearCase label can be put on any file. Rule like the one suggested by Gary
can very well end-up selecting 0 files, simply because the label '
DESIRED_LABEL' has not been put on the root-directory 'MyPath'!Plus there is no notion of "timeline" revision (like the revision in Subversion).
If the label prove too unreliable (because not put on all the files), a solution could be to combine the date of the label with a time-based rule.
'
date_Of_The_Label_Put' being the date of the application of the label on at least one element.If some elements had not been labeled, they would still be selected at the correct version, i.e. the version at the time of the label being applied partially on a set of files.