Is it possible to move folders from one set of TFS branches into another and preserve pending changes?

Question

At present, our TFS (TFVC, not git) project contains a folder that hosts the entirety of our product. This folder contains three branches (Dev, Main and Release) each of which in turn contains many different sub projects. We are attempting to restructure so that distinct components are contained within their own branching structure.

Question: Is it possible to move a folder that is contained under a branch (not the branch itself), along with its corresponding folder in the other branches into a new TFS project while maintaining the relationship and status of any unmerged changesets?

Here is a diagram of our desired end result:

We want to move each of the "Project 1" folders (left side) into their own branching structure (right side), but we need any unmerged changesets to "come along". That is to say that if we attempt to Merge from Dev to Main in the new structure we are presented with a list of the (pertinent) changesets that were not merged in the old structure.

Is this possible? If so, what series of tf/tfvc commands would we need to pull this off? I've gone deep into google, but came up short--either because I don't know how to describe this in a search friendly way, or its simply impossible.

What I've tried:

• Direct Move/Rename each of the folders into the new project (pre-creating each of the target Dev/Main/Release branches)

  • 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

• Branch each folder, into the new structure (this time without pre-creating the target branch folders)

  • 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)
  • Unlike the above, the files themselves ended up correct (nothing was overwritten).
  • The unmerged changesets were lost.
  • Shelvesets get unshelved to the original location

If it matters, we are willing to lose overall history if that's the only way to solve this. Preferably we'd keep it, even if it meant storing a 'deprecated' copy of the original somewhere. I'm not so concerned about shelvesets "following" their source either... we only have two that would be impacted and we can handle those manually if needed. We are using on-prem TFS 2018.

Edit: in response to an answer that was posted and then deleted:

I'm not looking to move the branches, but to extract folders deep inside them into their own corresponding branch structure without losing pending changes. I only show two levels above, but in reality they are a lot deeper. I am able to tf rename an entire branch in a sandbox and get expected results... but renaming branches is not what I'm trying to do, and moving the folders gives unexpected results.

Answer 1

It seems like you can achieve what you are wanting by having merge relationships from both the new Dev, Main, Release branches and the old project folders. I think you can do a variation of the second "route" you tried above.

1. Branch the old Release > Project[x] folder into the new Project[x] > Release branch
2. Branch the new Project[x] > Release Branch into the new Project[x] > Main branch
3. Merge (baseless) the old Main > Project[x] folder (specifying the changeset that the old Release was branched from) into the new Project[x] > Main branch
4. Branch the new Project[x] > Main Branch into the new Project[x] > Dev branch
5. Merge (baseless) the old Dev > Project[x] folder (specifying the changeset that old Main was branched from) into the new Project[x] > Dev branch
6. Repeat for the other Projects

The goal is to create the new branch merge relationships (by branching [new] Release to [New] Main and then [New] Main to [New] Dev. At this point the merge relationship has been established and all branches are in the same state. Then we baseless merge the [old] to the [new] for main and Dev. For Main we want to dot he baseless merge on the state where Main and Release are the same (in the old). For Dev we want to do the baseless merge on the state where Dev and Main are the same (in the old). Then additional merges may occur from [old] to [new] and these should be detected as merge-able changes from [new] to [new] similar to how they are in [old] to [old]

You will loose the shelve sets (but can always unshelve in the old location, checkin, and merge to the new) but history should be retained as long as the old project isn't destroyed.