我们正在考虑从ClearCase迁移到Subversion.该项目已经有一段时间了(7岁),有三个"重大"的版本(分支),我们积极支持,加上在旧版本的一些偶尔的修复.该项目相当大 - 大约2百万行java代码.
如果有人做过类似的迁移,我很好奇.
SVN能否处理这么大的项目？
迁移所有历史版本/分支是否有意义？有选择地可以做到的工具吗？
迁移过程需要多长时间来完成这样的项目,有效的工作方式是什么,然后迁移正在进行中？
VonC.. 9
为了进行这种迁移,我认为:
您无需将ClearCase版本的所有历史记录导入SVN.大多数时候(根据我的经验),只需要标记版本(一致地应用于给定集合的所有文件的版本),除非您真正需要细粒度的历史修订版本.
您需要考虑迁移过程中的重组:您导入什么？,您要离开什么？,您是否希望SVN内容完全反映存储在ClearCase VOB中的文件结构？有时,这种迁移是重新考虑其中一些文件组织的时机(通常通过对某些目录的简单重命名规则).
由于SVN是以存储库为中心并提交一组文件,因此ClearCase是以文件为中心的,并且逐个文件提交(非常缓慢),因此ClearCase 2 SVN方式的迁移速度更快
如果要明确标识要导入的文件集,则可以多次重复迁移过程,这意味着您可以在第一次(大型)导入时继续在ClearCase中工作,然后放置基线(UCM标签)您的代码,并仅重新导入增量,从而有效地结束迁移过程.
Jiri Klouda.. 5
首先是一些资源:
Clearvision CC2SVN工具
Polarion的SVN进口商
CollabNet上的文章和资源
实际存储库的大小,文件数量或大小不是SVN的限制因素.开发人员的数量,变更的并发性,集成和发布过程的复杂性,合并和目录版本控制(重构)的需要可能会给大型项目带来问题.如果您的项目很大,但它相当稳定,开发人员数量少,分支机构数量少,并且不需要向几个先前版本提供大量修补程序,SVN应该可以为您做好.
我编写了一个自定义迁移工具,将数据从ClearCase中取出,这不是一件容易的事.每两个系统对数据具有不同的数据模型和操作.我不建议尝试编写任何自定义迁移工具,因为实际上很难以任何有意义的方式从ClearCase中获取数据.有关商业解决方案限制的详细信息,我建议您联系资源中链接的解决方案提供商.
我个人会尝试尽可能多地提供数据,但您必须了解SVN与ClearCase相比的局限性.在此迁移过程中,任何目录版本控制(重构)历史记录都可能会丢失.SVN不支持像ClearCase这样的稀疏分支,如果您使用任务分支,它可能会膨胀SVN存储库的大小.在这种情况下,您可能希望仅限于系统分支.ClearCase中的文件具有单独的分支结构,而SVN具有每个产品的分支类型,这将导致在该过程中进行大量分支转换.通过将自己限制在系统分支中,并且可能只是在这些分支上标记版本以获得系列中完全集成的标签,您可以省去很多麻烦.如果您的团队正在使用UCM,您几乎可以忘记所有UCM元数据.
时间范围在很大程度上取决于所使用的工具.对于像你这样的重大项目,它甚至可能是数周.ClearCase数据库出于一些奇怪的原因,即使在读取操作上也存在大量锁定,并且存在一个中心表,其中所有内容都会在迁移等大规模访问中产生许多问题.我第一次在比你的产品稍大的产品上运行我的工具,我们估计它将运行3年,经过大量优化,并行化和增量迁移后,它减少到大约一周.但是,根据工具的完成程度,可能会出现很多差异.虽然自从迁移到SVN后,您将忽略ClearCase中的大量历史记录和元数据,但迁移速度应该快得多.
ClearVision在其网页上提到其CC2SVN工具可以在两种产品之间建立桥梁.虽然我没有使用这个工具,如果它按照我的假设工作,它会让你在一些处理后同步2个存储库,这将允许你进行一些周末切换,零开发停机时间.如果无法做到这一点,请尝试寻求一些替代方法,例如增量迁移,首先迁移到某个日期,然后迁移自该日期以来更改的较小数据块.
该过程的非常重要的部分是迁移后阶段.请不要忽视交换机给您的开发人员带来的麻烦.您不能低估培训和清晰文档的必要性.您还需要在您的软件工程部门中经过培训的支持团队,该团队能够操作两个SCM系统并向开发人员解释如何在新系统中执行他们习惯的操作.这实际上是一个可能在迁移中破坏你的关键点.开发人员抵制任何变化以及SVN为项目带来的任何优势,它本质上是低劣的系统.ClearCase为您的开发人员提供了他们在SVN中永远不会拥有的灵活性,除非您在此过程中尽早使用它们,否则您可能会丢失它们或者更糟糕的是,让整个迁移工作逆转,宣布灾难并失去自己的工作.
为了进行这种迁移,我认为:
您无需将ClearCase版本的所有历史记录导入SVN.大多数时候(根据我的经验),只需要标记版本(一致地应用于给定集合的所有文件的版本),除非您真正需要细粒度的历史修订版本.
您需要考虑迁移过程中的重组:您导入什么？,您要离开什么？,您是否希望SVN内容完全反映存储在ClearCase VOB中的文件结构？有时,这种迁移是重新考虑其中一些文件组织的时机(通常通过对某些目录的简单重命名规则).
由于SVN是以存储库为中心并提交一组文件,因此ClearCase是以文件为中心的,并且逐个文件提交(非常缓慢),因此ClearCase 2 SVN方式的迁移速度更快
如果要明确标识要导入的文件集,则可以多次重复迁移过程,这意味着您可以在第一次(大型)导入时继续在ClearCase中工作,然后放置基线(UCM标签)您的代码,并仅重新导入增量,从而有效地结束迁移过程.
首先是一些资源:
Clearvision CC2SVN工具
Polarion的SVN进口商
CollabNet上的文章和资源
实际存储库的大小,文件数量或大小不是SVN的限制因素.开发人员的数量,变更的并发性,集成和发布过程的复杂性,合并和目录版本控制(重构)的需要可能会给大型项目带来问题.如果您的项目很大,但它相当稳定,开发人员数量少,分支机构数量少,并且不需要向几个先前版本提供大量修补程序,SVN应该可以为您做好.
我编写了一个自定义迁移工具,将数据从ClearCase中取出,这不是一件容易的事.每两个系统对数据具有不同的数据模型和操作.我不建议尝试编写任何自定义迁移工具,因为实际上很难以任何有意义的方式从ClearCase中获取数据.有关商业解决方案限制的详细信息,我建议您联系资源中链接的解决方案提供商.
我个人会尝试尽可能多地提供数据,但您必须了解SVN与ClearCase相比的局限性.在此迁移过程中,任何目录版本控制(重构)历史记录都可能会丢失.SVN不支持像ClearCase这样的稀疏分支,如果您使用任务分支,它可能会膨胀SVN存储库的大小.在这种情况下,您可能希望仅限于系统分支.ClearCase中的文件具有单独的分支结构,而SVN具有每个产品的分支类型,这将导致在该过程中进行大量分支转换.通过将自己限制在系统分支中,并且可能只是在这些分支上标记版本以获得系列中完全集成的标签,您可以省去很多麻烦.如果您的团队正在使用UCM,您几乎可以忘记所有UCM元数据.
时间范围在很大程度上取决于所使用的工具.对于像你这样的重大项目,它甚至可能是数周.ClearCase数据库出于一些奇怪的原因,即使在读取操作上也存在大量锁定,并且存在一个中心表,其中所有内容都会在迁移等大规模访问中产生许多问题.我第一次在比你的产品稍大的产品上运行我的工具,我们估计它将运行3年,经过大量优化,并行化和增量迁移后,它减少到大约一周.但是,根据工具的完成程度,可能会出现很多差异.虽然自从迁移到SVN后,您将忽略ClearCase中的大量历史记录和元数据,但迁移速度应该快得多.
ClearVision在其网页上提到其CC2SVN工具可以在两种产品之间建立桥梁.虽然我没有使用这个工具,如果它按照我的假设工作,它会让你在一些处理后同步2个存储库,这将允许你进行一些周末切换,零开发停机时间.如果无法做到这一点,请尝试寻求一些替代方法,例如增量迁移,首先迁移到某个日期,然后迁移自该日期以来更改的较小数据块.
该过程的非常重要的部分是迁移后阶段.请不要忽视交换机给您的开发人员带来的麻烦.您不能低估培训和清晰文档的必要性.您还需要在您的软件工程部门中经过培训的支持团队,该团队能够操作两个SCM系统并向开发人员解释如何在新系统中执行他们习惯的操作.这实际上是一个可能在迁移中破坏你的关键点.开发人员抵制任何变化以及SVN为项目带来的任何优势,它本质上是低劣的系统.ClearCase为您的开发人员提供了他们在SVN中永远不会拥有的灵活性,除非您在此过程中尽早使用它们,否则您可能会丢失它们或者更糟糕的是,让整个迁移工作逆转,宣布灾难并失去自己的工作.
京公网安备 11010802040832号 | 京ICP备19059560号-6 