从 ClearCase 迁移到 SVN 时的最佳策略是什么？
我们正在考虑从 ClearCase 迁移到 Subversion。 该项目已经存在了一段时间（7 年），我们积极支持三个“主要”版本（分支），以及旧版本中的一些偶尔修复。 该项目相当大——大约 200 万行 java 代码。
我很好奇是否有人做过类似的迁移。
- SVN能处理这么大的项目吗？
- 迁移所有历史版本/分支是否有意义？ 是否有可以选择性地完成此操作的工具？
- 这样的项目的迁移过程需要多长时间？迁移过程中有效的工作方式是什么？
We are considering moving from ClearCase to Subversion. The project has been there for a while (7 years) and there are three "major" versions (branches) that we actively support, plus some occasional fixes in older releases. The project is fairly large - around 2 mln lines of java code.
I am curious if there is someone that has done similar migration.
- Will SVN be able to handle such a large project?
- Does it make sense to migrate all historical versions/branches? Are the tools that could do it selectively?
- How long will the migration process take for such a project and what is the effective way of working then the migration is in progress?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
对于进行了多次此类迁移，我认为：
您不需要将 ClearCase 版本的所有历史记录导入到 SVN 中。 大多数时候（根据我的经验），只需要标记版本（一致地应用于给定集的所有文件的版本），除非您确实需要进行细粒度的历史修订检查。
在迁移期间您需要考虑重组：导入什么？、留下什么？以及您是否希望 SVN 内容反映存储在 ClearCase VOB 中的文件结构到底是什么？ 有时，此类迁移需要重新考虑其中一些文件组织（通常通过某些目录的简单重命名规则）。
如果要导入的文件集是明确标识后，迁移过程可以重复多次，这意味着您可以在第一次（大型）导入发生时继续在 ClearCase 中工作，然后在代码上放置基线（UCM 标签），然后仅重新导入增量，有效地结束迁移过程。
For having made several migrations of this kind, I would argue that:
you do not need to import all the history of the ClearCase versions into SVN. Most of the time (for my experience), only the labeled versions (the one which are applied consistently on all the files of a given set) are needed, unless you have a real need for a fine-grained history revision examen.
you need to think about reorganization during a migration: what do you import ?, what do you leave ?, and do you want the SVN content reflect exactly the structure of the files as stored in the ClearCase VOB ? Sometime, such migrations are the occasion to rethink some of those files organization (usually through simple renaming rules for certain directories).
the migration is quicker in the ClearCase 2 SVN way, since SVN is repository-centric and commit a set of files, while ClearCase is file-centric and commits file-by-file (much sloooower)
if the set of files to import is clearly identified, the migration process can be repeated multiple times over, which means you can go on working within ClearCase while the first (large) import is taking place, then put a Baseline (UCM label) on your code, and re-import only the delta, effectively ending the migration process.
首先是一些资源：
实际存储库的大小、文件的数量或其大小并不是 SVN 的限制因素。 开发人员的数量、更改的并发性、集成和发布过程的复杂性、合并和目录版本控制（重构）的需要可能会给大型项目带来问题。 如果您的项目很大，但相当稳定，开发人员数量较少，分支数量较少，并且不需要将大量修复程序向后移植到多个先前版本，那么 SVN 应该适合您。
我编写了一个自定义迁移工具，将数据从 ClearCase 中取出，这不是一件容易的事。 每两个系统都有不同的数据模型和对数据的操作。 我不建议尝试编写任何自定义迁移工具，因为实际上很难以任何有意义的方式从 ClearCase 中获取数据。 有关商业解决方案限制的详细信息，我建议联系资源中链接的解决方案提供商。
我个人会尝试带来尽可能多的数据，但您必须意识到 SVN 与 ClearCase 相比的局限性。 在此迁移过程中，任何目录版本控制（重构）历史记录都可能会丢失。 SVN 不支持像 ClearCase 这样的稀疏分支，如果您使用任务分支，这可能会使 SVN 存储库的大小膨胀。 在这种情况下，您可能只想将自己限制在系统分支上。 ClearCase 中的文件具有单独的分支结构，而 SVN 具有按产品排序的分支，这将导致过程中出现大量分支转换。 通过将自己限制在系统分支上，并且可能只是在这些分支上标记版本以在该系列中完全集成标签，您可以为自己省去很多麻烦。 如果您的团队正在使用 UCM，您几乎可以忘记所有 UCM 元数据。 它们不会翻译成 SVN。
时间范围很大程度上取决于所使用的工具。 对于像您这样的大型项目，甚至可能需要几周的时间。 由于某种奇怪的原因，ClearCase 数据库即使在读取操作上也有大量锁定，并且所有内容都有一个中央表，这会在大规模访问（例如迁移）中产生很多问题。 我第一次在比你的产品稍大的产品上运行我的工具时，我们估计它会运行 3 年，经过大量优化、并行化和增量迁移后，它减少到大约一周。 但预计根据工具的完成程度，所需的时间可能会有很大差异。 尽管由于您迁移到 SVN 并且您将忽略来自 ClearCase 的大量历史记录和元数据，但您的迁移应该会快得多。
ClearVision 在其页面上提到其 CC2SVN 工具可以在两种产品之间建立桥梁。 虽然我没有使用这个工具，但如果它像我想象的那样工作，它会让你在一些处理后同步 2 个存储库，这将允许你在周末进行切换，并且开发停机时间为零。 如果这不可能，请尝试寻求一些替代方案，例如增量迁移，首先迁移到某个日期，然后迁移自该日期以来更改的较小数据块。
该过程中非常重要的部分是迁移后阶段。 请不要低估这种切换会给开发人员带来的麻烦。 您绝不能低估培训和清晰文档的需求。 您的软件工程部门还需要一支训练有素的支持团队，能够操作两个 SCM 系统，并向开发人员解释如何在新系统中执行他们习惯的操作。 这实际上是迁移过程中可能会折断你脖子的一点。 开发人员抵制任何改变，无论 SVN 给项目带来什么优势，它本质上都是低劣的系统。 ClearCase 为您的开发人员提供了SVN 所无法提供的灵活性，除非您在流程的早期就让他们加入，否则您可能会失去他们，甚至更糟，导致整个迁移被逆转，宣告一场灾难并失去自己的工作。
First some resources:
The size of the actual repository, number of files or their sizes are not a limiting factor for SVN. The number of developers, concurrency of changes, complexity of the integration and release process, need for merging and directory versioning ( refactoring ) could pose problems for a large project. If your project is just large, but it is fairly stable, with low number of developer, small number of branches and no need for backporting of tons of fixes to several prior releases, SVN should do just fine for you.
I have written a custom migration tool bringing data out of ClearCase and it is not easy task. Every two systems have different data models and operations over the data. I would not suggest to try to write any custom migration tool, because it is very hard to actually get data out of ClearCase in any meaningful way. For details on limitations of commercial solutions I would suggest to contact the solution providers linked in resources.
I personally would try to bring over as much data as possible, but you have to be aware of limitations of SVN compared to ClearCase. Any directory versioning ( refactoring ) history will likely get lost during this migration. SVN does not support sparse branches like ClearCase, which could bloat the size of your SVN repository in case you used task branches. In that case you probably want to limit yourself to system branches only. Files in ClearCase have individual branching structure, while SVN has branches sort of per product, which will result in a lot of branch translation in the process. By restricting yourself to system branches and maybe just labeled version on those branches for fully integrated labels in the series, you could save yourself a lot of trouble. In case your team is using UCM, you can pretty much forget all the UCM metadata. They will not translate into SVN.
The timeframe depends largely on the tools used. For a major project like you have it could be even weeks. ClearCase database has for some weird reason lots of locking even on reading operations and there is one central table of everything which creates a lot of problems in large scale access like migration would cause. The first time I run my tool on product somewhat larger than yours, we estimated it would run for 3 years, after much optimization, parallelization and incremental migration it cut down to about a week. But expect that depending on how well the tool is done, there could be a lot of variance in the time it takes. Although since you migrate into SVN and you will ignore a lot of the history and metadata from ClearCase, your migration should be much faster.
ClearVision, mentions at its pages that its CC2SVN tool can create a bridge between the two products. Although I did not use this tool, if it works as I assume, it would let you sync the 2 repositories after some processing, which would allow you some weekend switchover, with zero development downtime. If this is not possible try to ask for some alternative like incremental migration, where you first migrate up to some date, then migrate a smaller chunk of data changed since that date.
Very important part of the process is the post migration phase. Please do not discount the headaches the switch will bring to your developers. You must not underestimate the need for training and clear documentation. You will also need a trained support team in your software engineering department capable to operate both SCM systems and to explain to developers how to do things they were used to in the new system. This is actually a point that could break your neck in the migration. Developers resist any change and whatever advantages SVN brings to the project, it is in essence much inferior system. ClearCase gives your developers so much flexibility they will never have with SVN and unless you bring them on board early on in the process, you can lose them or worse, get the whole migration reversed, declared a disaster and lose your own job.
如果你决定搬家，你可以看看这个 stackoverflow 问题。
recommendation-on-tools-to-migrate-from-clearcase-到-svn
if you decide to move, you can look at this stackoverflow question.
recommendation-on-tools-to-migrate-from-clearcase-to-svn
另一个选项是 Migrate2SVN。 开发商 (Clearvision) 刚刚发布了 v2.0，它似乎包含了对 Polarion 软件和上述其他方法的许多改进。
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.