I want to clean up our mainline branch by moving many files to an "Archive" folder outside the branch. These files still exist in the branches that are branched from mainline. What will happen the next time I merge to these other branches? Will the files I moved be deleted out of the target branches? Will they be moved somewhere? Or left alone?
Also, will the files I archived still have a link to the files in the other branches?
When you move a file to another folder (say Archive), it will delete the file from your Main branch and then do a "Source Rename" operation to point it to the new location (Archive folder). The change that happens in your Mainline branch is the "Delete" operation, so the next time you merge your Main branch to the other chid branches it will "delete" the file from that child branches as well.
Related
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.
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.
Branch the old Release > Project[x] folder into the new Project[x] > Release branch
Branch the new Project[x] > Release Branch into the new Project[x] > Main branch
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
Branch the new Project[x] > Main Branch into the new Project[x] > Dev branch
Merge (baseless) the old Dev > Project[x] folder (specifying the changeset that
old Main was branched from) into the new Project[x] > Dev branch
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.
I have made some changes in a branch which involve renaming the sub-dir a project's code files live in, and committed this branch. I was unaware that while I was working on my branch, another developer made changes to one of the source files in this sub-directory and committed this.
When I merged my branch, it didn't detect the other developer's changes and undid them silently, which we only found later. When I try to re-apply their changeset, it just restores the files in their previous location.
I can manually re-apply their changes since it's an isolated case, but is there actually a way I can apply a changeset in this scenario, tell TFS the two directories are equivalent or something?
In your scenario, you can use tf merge command from command line with /recursive keyword, as since there is no way to specify the old name of the source branch from the UI, but we can from the TF merge command line.
I have a common brach "root" and several child branches. A project with a huge amount of changesets is merged back to the root brach, but a several files have been excluded since the were not nescessary. Those were no seperated changesets.
Now I want to start a new project on that branch, but when I attempt to merge this new project back to the root branch, former excluded files occur again.
So, in between projects for the child branch, it is possible to erase all pending changes compared to root branch?
If these files do not need to be tracked by Version Control, you can create a tfignore file to exclude them.
If these files need to be tracked by Version Control in the child branch but does not need to be merged into root branch, you can use tf merge command with "/discard" specified.
/discard: Does not perform the merge operation, but updates the merge
history to track that the merge occurred. This discards a changeset
from being used for a particular merge.
I have a project setup with the folder structure underneath
Project
Archive
Source
Development
Source
I want to move some old branches under Development/Source to Archive/Source. I can move it, however, when I try to commit the changes for the move, it states that the branch already exists. I can view all deleted branches and I cant see anything in the archive folder which state that it already exists.
Try converting deleted branches into folders. Maybe that helps.
I have a branch created some time ago in TFS of our main trunk branch. I've periodically been merging trunk->branch to keep it up to date and now I'm ready to push back to trunk.
I have modified about 10 files in 3 projects, however when doing the merge TFS marks 7000 files as modified, seemingly every file in the branch. I can see that the files are nor modified in every case I check but I don't dare check them in without checking every file and clearly that's no good in this case!
In the Source Control Explorer view, all these files and folders are marked as "merge" in the "Pending Change" column.
Can I fix things somehow or do I need to undo the merge and manually merge only the files I know I actually modified, breaking the whole point of merging?
Reasons for this might be one of the listed items in Why are all files marked with 'merge' in TFS?
But there are other cases as well:
Another branch of the target branch had itself a branch that was renamed then merged to the child branch then that child branch was merged to your target branch;
There was a move or rename of your branch and it was rolled back (but you can see it in the changesets still);
The way I solved it was to do a merge using the "Selected changesets" instead of "All changes up to a specific version". Then in the following dialog, exclude the renaming attempts.
Once this is done, you will still have these changesets in the history bugging you for every merge, so you might want to discard them with "tf merge /discard".