version-control - Team Foundation Server - 随历史移动源

Question

我想知道将带有历史记录的源代码从一个团队项目移动到另一个团队项目的最佳方法是什么。我不关心工作项、报告或 SharePoint 站点，因为我们要从中恢复的系统没有使用这些功能。想要转移到不同团队项目的原因还在于原始实现(从第三方维护的备份中恢复)使用了我们不希望使用的第三方流程模板向前走。我们希望在迁移完成后开始利用工作项跟踪和报告。

TFS Integration Platform这似乎是一种可能的情况。根据文档，它可用于更改流程模板。但是，我很好奇 tf.exe 移动语法是否有效？像这样的东西:

tf.exe 移动 $/ProjectA $/ProjectB

据我了解，此命令的操作非常类似于重命名操作，而使用源代码管理资源管理器中的“移动”上下文菜单项进行移动更像是删除和添加操作。另外，假设 $/ProjectA 是一个项目的根源代码控制文件夹，$/ProjectB 是另一个项目的根源代码控制文件夹，tf.exe 移动路径实际上是否会将文件夹下的代码与相应的团队项目相关联？关键是如果可能的话，能够保留历史记录。

任何建议或提示将不胜感激!

编辑 - 可以分支到另一个项目来处理这种情况 - 就像 Microsoft 在 Branching Guidance 中讨论的那样文档？我认为这可能是答案，因为历史可能会与分支一起保存。但是，我目前无法访问 Team Foundation Server 2008 实例来对其进行测试。

Answer 1

移动和重命名是别名。在任何版本的 TFS 中，无论是命令行还是 UI，绝对没有区别。

它们都保存了历史。至少在 2005/2008 年，无论名称和/或父路径更改的频率或程度如何，您都会在 VersionedItem 表中保留相同的物理项目。实际上，如果您不进行大量手动工作，就无法获得“假”重命名(删除+添加)。

然而，虽然这个版本控制模型在理论上非常纯粹，但它有一些实际问题。由于不同的项目可以在不同的时间点占用相同的名称，因此 TFS 需要全名 + 版本来唯一标识您发送给它的任何输入。通常你不会注意到这个限制，但是一旦你重命名了系统中的项目，如果你说 tf [doSomething] $/newname -version:oldversion 那么它会变得困惑并且抛出错误或对您可能无意的项目进行操作。您必须小心传递有效的组合(新名称+新版本或旧名称+旧版本)，以确保命令按照您想要的方式运行。

TFS 2010 稍微改变了情况:它是幕后的分支+删除，导致 itemID 发生变化。即便如此，像 Get 和 History 这样的日常命令还是可以很好地“伪造”的。老客户端兼容率达到95%左右。优点是，当您在系统中进行多个重命名并且基于路径的项目查找开始变得不明确(如上面提到的)时，服务器将简单地接受您指定的名称并使用它运行。这提高了整体系统性能并消除了不熟悉的用户经常陷入的几个陷阱，但代价是不够灵活并且不能以 100% 的精度保留历史记录(例如，当两个分支合并期间出现名称冲突时)。

回到手头的问题......

这并不像说tf rename $/projectA $/projectB那么简单。源代码管理树中的顶级文件夹是为团队项目创建向导保留的；您无法对它们运行标准 tf 命令。您需要的是这样的脚本:

Get-TfsChildItem $/ProjectA |
    select -Skip 1 |  # skip the root dir
    foreach {
        tf rename $_.serveritem $_.serveritem.replace("$/ProjectA", "$/ProjectB")
    }

【当然，如果$/ProjectA下子节点不是太多，也可以手工完成】

就我提到的陷阱而言，我现在将详细说明一个问题，因为查找旧历史对您来说似乎非常重要。一旦您 checkin 重命名，tf History $/ProjectA/somefile.cs 将不起作用。默认情况下，tf 命令假定版本 =“最新”。这些替代方案中的任何一个都将是您想要的完整历史记录:

• tf History $/ProjectA/somefile.cs;1234 更改集 1234 位于移动之前
• tf History $/ProjectB/somefile.cs;5678，其中变更集 5678 位于移动之后。或者您可以省略版本。

出于完整性和调试目的的最终替代方案:

• tf 历史记录 $/ProjectA/somefile.cs -slotmode。您只会看到移动之前发生的更改；但是，您还会看到在您移动到 ​​B 下的项目之前或之后可能存在于 $/ProjectA/somefile.cs“槽”中的任何其他项目的历史记录。

(在 TFS 2010 中，“槽模式”是默认行为；有一个 -ItemMode 选项可以请求跨历史记录跟踪您的查找，就像 2008 年一样，而不是基于路径。)

编辑 - 不，分支不是一个很好的选择。虽然分支确实在系统中留下了足够的元数据来跟踪 ProjectB 的完整历史记录，但在 2008 年，它对用户来说并不是非常友好。计划花大量时间学习 tf merges 命令(没有等效的 UI) )。 2010 极大地提高了您可视化跨多个分支的更改的能力，但它仍然不是您从重命名中获得的干净统一的体验。