是否可以将文件夹从一组TFS分支移动到另一组，并保留挂起的更改？

Question

目前，我们的TFS (TFVC，而不是git)项目包含一个包含我们整个产品的文件夹。此文件夹包含三个分支(开发、主和发行)，每个分支依次包含许多不同的子项目。我们正试图进行重组，以便将不同的组件包含在它们自己的分支结构中。

问:是否可以将包含在分支(而不是分支本身)下的文件夹及其在其他分支中的相应文件夹移动到新的TFS项目中，同时保持任何未合并变更集的关系和状态？

下面是我们想要的最终结果的图表：

​

​

我们希望将每个"Project 1“文件夹(左侧)移动到它们自己的分支结构(右侧)中，但是我们需要任何未合并的变更集来”来“。也就是说，如果我们试图在新结构中从Dev合并到Main，那么我们将收到一个未在旧结构中合并的(相关的)变更集的列表。

这个是可能的吗？如果是这样的话，那么tf**/tfvc命令系列的**我们需要完成这个任务吗？我深入到了谷歌，但出现的时间很短--要么是因为我不知道如何用搜索友好的方式来描述这个问题，要么是根本不可能。

我试过的是：

• 将每个文件夹直接移动/重命名到新项目中(预先创建每个目标开发/主/发布分支)

- The unmerged changesets were lost.
- All I get is a single "move/rename" changeset that appears in the unmerged list for the new branches. Merging _that_ causes everything in the target branch to be overwritten (ie. release branch's files are now the same as dev). 
- On the +side, pending shelvesets "auto-follow" when unshelved

​

• 将每个文件夹分支到新结构中(这一次没有预先创建目标分支文件夹)

- This created three branches that weren't related to each other. 
- I was able to solve that by doing a baseless merge between them (`tf merge /baseless /recursive`) and taking target branch files when conflicted; followed by re-parenting the branches. (As explained [here](https://alistairbmackay.wordpress.com/2014/01/15/tfs-reparenting-a-branch/))
- Unlike the above, the files themselves ended up correct (nothing was overwritten). 
- The unmerged changesets were lost.
- Shelvesets get unshelved to the _original_ location

​

如果它重要，我们愿意失去整个历史，如果这是解决这一问题的唯一途径。我们最好保留它，即使它意味着将原版本的“废弃”副本存储在某个地方。我也不太关心架子的来源.我们只有两个会受到影响，如果需要，我们可以手动处理。我们使用的是2018年预赛TFS。

编辑:在回复被张贴并删除的答复时：

我并不是要移动分支，而是要将文件夹提取到它们内部的深处--到它们自己对应的分支结构中，而不会丢失挂起的更改。我在上面只展示了两个层次，但实际上它们要深得多。我可以在沙箱中tf rename整个分支，并得到预期的结果.但是重命名分支不是我想要做的，移动文件夹会产生意想不到的结果。

Answer 1

似乎您可以通过从新的开发、主、发布分支和旧的项目文件夹中获得合并关系来实现您想要的结果。我认为你可以做第二个“路线”的变化，你尝试了上面。

1. 将旧发布> Projectx文件夹分支到新项目>发布分支
2. 将新项目>发布分支分支到新项目>主分支
3. 将旧 Main > Projectx文件夹(指定旧版本分支的变更集)合并到新项目>主分支中
4. 将新项目>主分支分支到新项目>开发分支
5. 将旧 Dev > Projectx文件夹(指定旧 Main分支的变更集)合并到新项目> Dev分支中
6. 重复其他项目

目标是创建新的分支合并关系(通过将新版本分支到new，然后将new )。此时，已经建立了合并关系，所有分支都处于相同的状态。然后，我们把旧的和新的合并为main和Dev。主要而言，我们希望在相同的状态(在旧版本中)上点缀无根据的合并。对于Dev，我们希望在Dev和Main相同的状态(在旧的)上进行无根据的合并。然后，更多的合并可能会从旧的到新的，这些应该被检测为从新到新的可合并的变化，类似于它们在旧到旧之间的变化。

您将松开搁置集(但始终可以在旧位置解架、签入并合并到新的)，但只要旧项目未被破坏，历史记录就应该保留。