问SVN到Clearcase导出

EN

我直接在Git视图中使用ClearCase。

然后，如果我有一个要同步的SVN，我可以将内容返回到SVN。

注意:对于直接在ClearCase视图中工作的工具，我必须使用快照视图，以便写入文件，即使这些文件尚未签出。然后，对于我认为已经完成的任何活动，我都会更新快照视图，它允许我列出所有被劫持的文件。我检查他们，然后登记他们。

在这种情况下(客户端的ClearCase回购)，我会看到使用SVN的问题是：

• 引入了另一个中央存储库(意为提交，您必须访问您的专用中心SVN存储库，对于“到客户端提交”，您必须访问中央ClearCase VOB版本对象库，即ClearCase术语中的“存储库”)。
• 引入了另一个分支建模，其中在SVN中，它是一个目录中的廉价副本，而在ClearCase中，它是一个元数据(分支)，而不是一个目录。这意味着SVN签出的物理树可能与ClearCase中的快照视图更新不匹配，因为SVN签出的某些目录在ClearCase中根本不存在。

至少，对于Git，你有：

• 私有存储库(您没有添加其他每个人都应该访问的中央存储库)
• 相同的分支模型(至少在“不通过目录表示分支”时是这样)

我们需要这个来完成我的一个项目。该团队在svn中表现得更好，公司标准是ClearCase。因此，我编写了一个脚本，继续将主干迁移到clearcase，并在构建服务器上运行它。

我把脚本放在这里：http://dvae.net/blog/2009/09/clearcase-to-svn/

我们所做的是在构建服务器上设置一个作业，该作业定期运行，并使用clearfsimport进行迁移。我们使用了Luntbuild作为构建服务器，但是巡航控制也可以正常工作。就像正常的构建一样，我们将脚本设置为只有当svn修改被检测到时才运行。我们每20分钟运行一次作业，因为ClearCase服务器位于不同的国家，所有操作都很慢，同步需要40分钟才能运行。我建议你尽可能多地跑步。

该脚本基于ClearCase UCM，如果您不需要删除“cleartool mkact”，最后创建一个标签而不是基线。

我将clearcase注释设置为自上次同步以来所有SVN提交的级联。

我发现它是可靠的，而它失败的唯一原因是Clearcase触发器(像“邪恶的孪生”触发器)阻止了签入。当这种情况发生时，构建失败，Lunbuild发送一封电子邮件，然后我必须手动进行反向历史合并，以消除邪恶的孪生问题，提交和重新运行。

FYI :它可能在某种程度上对你有用：从SVN迁移到ClearCase

这并不同步数据，但如果需要迁移，它可能会有所帮助。