是否可以将文件夹从一组 TFS 分支移动到另一组并保留挂起的更改？
Is it possible to move folders from one set of TFS branches into another and preserve pending changes?
目前，我们的 TFS（TFVC，不是 git）项目包含一个存放我们整个产品的文件夹。此文件夹包含三个分支（Dev、Main 和 Release），每个分支又包含 许多 个不同的子项目。我们正在尝试重组，以便将不同的组件包含在它们自己的分支结构中。
问题：是否可以将包含在分支下的文件夹（不是分支本身）连同其他分支中的相应文件夹一起移动到 new TFS项目同时维护任何未合并的变更集的关系和状态？
这是我们想要的最终结果的图表：
我们想将每个 "Project 1" 文件夹（左侧）移动到它们自己的分支结构（右侧）中，但我们需要任何未合并的变更集到 "come along"。也就是说，如果我们尝试在新结构中从 Dev 合并到 Main，我们会看到一个未合并到旧结构中的（相关）变更集列表。
这可能吗？如果是这样，我们需要 什么系列的 tf/tfvc 命令 来实现它？我已经深入研究了 google，但结果很短——要么是因为我不知道如何以搜索友好的方式描述它，要么就是根本不可能。
我尝试过的：
直接Move/Rename每个文件夹到新项目中（预创建每个目标Dev/Main/Release分支）
- 未合并的变更集已丢失。
- 我得到的只是一个 "move/rename" 变更集，它出现在新分支的未合并列表中。合并 that 会导致目标分支中的所有内容都被覆盖（即，release 分支的文件现在与 dev 相同）。
- 在 + 方面，待处理的搁置集 "auto-follow" 未搁置时
将每个 文件夹 分支到新结构中（这次不预先创建目标分支文件夹）
- 这创建了三个彼此不相关的分支。
- 我能够通过在它们之间进行无根据的合并（
tf merge /baseless /recursive）并在发生冲突时获取目标分支文件来解决这个问题；然后重新设置分支。 （如解释here）
- 与上面不同的是，文件本身最终是正确的（没有被覆盖）。
- 未合并的变更集已丢失。
- 搁置集被取消搁置到原始位置
如果这很重要，如果这是解决这个问题的唯一方法，我们愿意失去整个历史记录。我们最好保留它，即使这意味着在某处存储原始文件的 'deprecated' 副本。我也不太关心搁置集 "following" 它们的来源……我们只有两个会受到影响，如果需要，我们可以手动处理它们。我们正在使用本地 TFS 2018。
编辑：回应已发布然后删除的答案：
我不是要移动分支，而是要提取文件夹 深入到它们自己相应的分支结构中，而不会丢失挂起的更改。我只展示了上面的两个层次，但实际上它们要深得多。我能够 tf rename 沙箱中的整个分支并获得预期的结果......但重命名分支并不是我想要做的，移动文件夹会产生意想不到的结果。
看来您可以通过合并新 Dev、Main、Release 分支 和 旧项目文件夹的关系来实现您想要的。我认为你可以对上面尝试的第二个 "route" 做一个变体。
- 将 old Release > Project[x] 文件夹分支到 new Project[x] > Release 分支
- 将 new 项目[x] > 发布分支分支到 new 项目[x] > 主分支
- 合并（无基础）old Main > Project[x] 文件夹（指定变更集
old 版本从分支到 new Project[x] > Main branch
- 将 new 项目[x] > 主分支分支到 new 项目[x] > 开发分支
- 合并（无基础）old Dev > Project[x] 文件夹（指定变更集
old Main 被分支到 new Project[x] > Dev branch
- 对其他项目重复
目标是创建新的分支合并关系（通过将 [new] Release 分支到 [New] Main，然后将 [New] Main 分支到 [New] Dev。此时合并关系已经建立并且所有分支处于相同状态。然后我们将 [old] 无基础地合并到 [new] 主和 Dev。对于 Main，我们想在 Main 和 Release 相同的状态（旧）上进行无基础合并。对于 Dev，我们希望在 Dev 和 Main 相同的状态（旧的）上进行无基础合并。然后可能会从 [old] 到 [new] 发生额外的合并，这些应该被检测为来自 [ new] 到 [new] 类似于它们在 [old] 到 [old]
您将松开搁置集（但始终可以在旧位置取消搁置、签入并合并到新位置）但只要旧项目未被破坏，历史记录就应该保留。
目前，我们的 TFS（TFVC，不是 git）项目包含一个存放我们整个产品的文件夹。此文件夹包含三个分支（Dev、Main 和 Release），每个分支又包含 许多 个不同的子项目。我们正在尝试重组，以便将不同的组件包含在它们自己的分支结构中。
问题：是否可以将包含在分支下的文件夹（不是分支本身）连同其他分支中的相应文件夹一起移动到 new TFS项目同时维护任何未合并的变更集的关系和状态？
这是我们想要的最终结果的图表：
我们想将每个 "Project 1" 文件夹（左侧）移动到它们自己的分支结构（右侧）中，但我们需要任何未合并的变更集到 "come along"。也就是说，如果我们尝试在新结构中从 Dev 合并到 Main，我们会看到一个未合并到旧结构中的（相关）变更集列表。
这可能吗？如果是这样，我们需要 什么系列的 tf/tfvc 命令 来实现它？我已经深入研究了 google，但结果很短——要么是因为我不知道如何以搜索友好的方式描述它，要么就是根本不可能。
我尝试过的：
直接Move/Rename每个文件夹到新项目中（预创建每个目标Dev/Main/Release分支）
- 未合并的变更集已丢失。
- 我得到的只是一个 "move/rename" 变更集，它出现在新分支的未合并列表中。合并 that 会导致目标分支中的所有内容都被覆盖（即，release 分支的文件现在与 dev 相同）。
- 在 + 方面，待处理的搁置集 "auto-follow" 未搁置时
将每个 文件夹 分支到新结构中（这次不预先创建目标分支文件夹）
- 这创建了三个彼此不相关的分支。
- 我能够通过在它们之间进行无根据的合并（
tf merge /baseless /recursive）并在发生冲突时获取目标分支文件来解决这个问题；然后重新设置分支。 （如解释here） - 与上面不同的是，文件本身最终是正确的（没有被覆盖）。
- 未合并的变更集已丢失。
- 搁置集被取消搁置到原始位置
如果这很重要，如果这是解决这个问题的唯一方法，我们愿意失去整个历史记录。我们最好保留它，即使这意味着在某处存储原始文件的 'deprecated' 副本。我也不太关心搁置集 "following" 它们的来源……我们只有两个会受到影响，如果需要，我们可以手动处理它们。我们正在使用本地 TFS 2018。
编辑：回应已发布然后删除的答案：
我不是要移动分支，而是要提取文件夹 深入到它们自己相应的分支结构中，而不会丢失挂起的更改。我只展示了上面的两个层次，但实际上它们要深得多。我能够 tf rename 沙箱中的整个分支并获得预期的结果......但重命名分支并不是我想要做的，移动文件夹会产生意想不到的结果。
看来您可以通过合并新 Dev、Main、Release 分支 和 旧项目文件夹的关系来实现您想要的。我认为你可以对上面尝试的第二个 "route" 做一个变体。
- 将 old Release > Project[x] 文件夹分支到 new Project[x] > Release 分支
- 将 new 项目[x] > 发布分支分支到 new 项目[x] > 主分支
- 合并（无基础）old Main > Project[x] 文件夹（指定变更集 old 版本从分支到 new Project[x] > Main branch
- 将 new 项目[x] > 主分支分支到 new 项目[x] > 开发分支
- 合并（无基础）old Dev > Project[x] 文件夹（指定变更集 old Main 被分支到 new Project[x] > Dev branch
- 对其他项目重复
目标是创建新的分支合并关系（通过将 [new] Release 分支到 [New] Main，然后将 [New] Main 分支到 [New] Dev。此时合并关系已经建立并且所有分支处于相同状态。然后我们将 [old] 无基础地合并到 [new] 主和 Dev。对于 Main，我们想在 Main 和 Release 相同的状态（旧）上进行无基础合并。对于 Dev，我们希望在 Dev 和 Main 相同的状态（旧的）上进行无基础合并。然后可能会从 [old] 到 [new] 发生额外的合并，这些应该被检测为来自 [ new] 到 [new] 类似于它们在 [old] 到 [old]
您将松开搁置集（但始终可以在旧位置取消搁置、签入并合并到新位置）但只要旧项目未被破坏，历史记录就应该保留。