团队计划从RTC迁移至TFVC，如何迁移代码及变更历史？

我之前帮团队处理过类似的RTC到TFVC的迁移需求，结合官方工具和实际踩坑经验，整理了几个可行方案，其中基于IBM官方迁移工具+TFVC命令行的组合方案是最稳妥、能完整保留历史的最优选择，下面详细拆解：

核心最优方案：IBM RTC迁移工具 + TFVC CLI #

这个方案能完整保留所有变更历史（提交者、时间戳、提交注释、文件变更细节、分支/标签结构），适合大规模代码库或对历史追溯要求高的团队。

操作步骤 #

• 环境准备：
  1. 安装并配置RTC客户端（确保能访问目标RTC仓库，拥有读取所有历史的权限）；
  2. 安装Azure DevOps Server/TFS客户端（必须包含tf命令行工具，用于后续导入操作）；
  3. 提前清理RTC仓库：删除废弃分支、无效标签、冗余的临时文件，减少迁移数据量。
• 导出RTC历史：
  使用IBM官方提供的RTC Version Control Export Tool，选择要迁移的代码路径，导出包含完整变更集历史的打包文件（支持XML或专用格式）。导出时可以通过参数过滤不需要的历史版本，比如只保留近2年的变更，或者排除特定分支。
• 转换并导入TFVC：
  1. 用自定义PowerShell脚本（或微软社区提供的辅助脚本）将RTC导出的变更集格式转换为TFVC兼容的结构，重点映射提交者身份、变更时间、注释内容；
  2. 使用tf import命令按时间顺序逐个导入变更集，确保历史的连贯性。如果有分支合并记录，需要单独处理TFVC的合并逻辑（TFVC的合并历史记录方式和RTC略有差异，建议提前测试1-2个合并场景）；
• 验证：
  导入完成后，对比RTC和TFVC的：
  • 最新代码版本的文件完整性；
  • 关键变更集的提交内容、注释、作者；
  • 分支和标签的结构是否一致。

优缺点 #

• 优点：官方工具稳定性强，完整保留所有历史信息，支持大规模代码库；
• 注意事项：迁移前一定要做小范围测试，确认合并历史的转换效果；如果RTC中有大量的跨分支合并，可能需要额外调整转换脚本。

备选方案1：Git中转（适合中小规模代码库） #

如果团队对合并历史要求不高，且代码库规模较小，可以用Git作为中转桥梁，操作更简单：

操作步骤 #

• 把RTC仓库镜像到Git：通过RTC的Git Bridge插件，使用git clone --mirror <RTC仓库地址>命令，将RTC的代码和完整历史同步到本地Git仓库；
• 把Git仓库导入TFVC：使用Azure DevOps的“导入仓库”功能，或者tf git import命令，将Git仓库的历史转换为TFVC的变更集。

优缺点 #

• 优点：操作门槛低，不需要复杂的工具配置，Git生态的工具可以帮助中途清理历史；
• 缺点：Git和TFVC的分支模型差异较大，合并历史可能丢失或变形，大规模代码库容易出现转换失败的情况。

备选方案2：手动迁移（仅适合极小代码库） #

如果团队完全不需要保留变更历史，只是需要把最新代码迁移到TFVC，可以直接复制粘贴：

操作步骤 #

• 从RTC拉取最新版本的代码；
• 在TFVC中创建新仓库，将代码上传并提交；
• 手动在TFVC的提交注释中简要说明代码来源。

优缺点 #

• 优点：耗时最短，不需要任何工具；
• 缺点：完全丢失所有变更历史，不适合需要追溯问题、合规要求的团队。

总结 #

如果你的团队需要完整保留变更历史，且代码库规模较大，**核心方案（IBM迁移工具+TFVC CLI）**是最优选择；如果是中小规模且对合并历史要求不高，可以考虑Git中转方案；手动迁移只适合临时应急场景。

内容的提问来源于stack exchange，提问作者sandy