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.
Related
I need to merge a changeset to another branch in TFS. But unfortunately, due to an unwanted code checkin happened in this changeset, I cannot merge the full changeset to the new branch. Therefore I need to skip the unwanted files from the changeset and merge other files to the new branch. Is there are a possibility of doing that? Ps: Since the changeset is huge I cannot merge it manually.
You can do this, what you are going to achieve kind like a partial merge.
A partial merge is recorded when only some changes from a changeset are merged into the target. There are two common scenarios in below which you can end up with partial merges:
Scenario 1:Undo some pending changes when you are checking the merged files
In this case, even though we already merged changeset Dev to Main, it is still a merge candidate. This is caused by the fact that the merge engine detected that there are still some changes in that changeset which were not propagated from Dev to Main.
Scenario 2: Performed the merge at feature level not from the top of the branch
For example: consider that you have two branches Main and Dev, each of them has two folders (Feature1 and Feature2) and each feature folder contains one file. We edit both files from the feature folders (Dev\Feature1\feature1.txt and Dev\Feature2\feature2.txt) and check-in the changes.
If you perform the merge operation at the Feature1 level.（Changset142→
Changeset143） You will notice in the Pending Changes window that only the edit done in the Feature1 folder will be merged. Complete the merge.
If you take a look at the merge history of the Feature1 folder you will see that all changes from changeset 142 have been merged into changeset 143.
However,if you take a look at the merge history of Main you will see that only parts of changeset 142 have been merged into changeset 143. This is normal as changeset 142 has some changes – the edit of the file in the Feature2 folder – which were not delivered.
In case of a partial merge, to figure out what changes have been merged and what changes from the changeset were left out. The only way to achieve this is to diff the contents of the changeset that was partially merged, and the contents of the changeset that was generated as the result of the merge. More detail info you can refer this blog: Partial Merges in TFS – A Guide
So, if your unwanted code only exist single or few files, you could follow scenario 1, undo those files.
If those files sill contain some other need changes, then I would suggest you directly merge all changes and create a new changeset after merge operation to exclude those unwanted code.
This should be the simplest solution.
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.
Background
If I merge our main branch to our development branch, TFS will state that there are no changes to commit. And yet, a file level comparison (using WinMerge) clearly shows that there are differences (e.g. files missing, files with different content, etc.).
In short, our main and development branches are no longer in sync which is most likely due to changesets that were lost during previous TFS migrations.
Question
What is the best way to produce the following?
Synchronizing the main and development branches by: performing all of the necessary insert/update/delete operations on the development branch. (i.e. main is the master copy).
At the end of the process WinMerge should indicate that there are zero (0) differences between the two branches.
Keeping the development branch history intact.
Notifying TFS that the development branch is now fully synchronized with main so that:
TFS won't try to merge older development changesets with main
only future changes to development will be pushed to main during a merge operation.
TFS is not my area of expertise - any guidance that you can provide would be greatly appreciated.
Context
Visual Studio 2015
TFS (version 14.95.25122)
References
Merge Command
"Performs a merge without a base version. That is, allows the user to merge files and folders that do not have a merge relationship. After a baseless merge, a merge relationship exists, and future merges do not have to be baseless."
Although Development was branched from Main, it looks like this might address my lack of history (i.e. missing changesets) problem.
TFS Merge: Best Practices
TFS: Overwrite a branch with another
tf merge A B -r -force -version:T
I don't think this will work for us because changesets are missing.
When TFS does a merge, it bases the merge on prior merge history, not on the actual contents of the source and target files.
This issue may by caused by picking keep target when perform merge or at one time, a merge with the discard option performed (using the command line TF merge /discard).
To solve this issue, you can try to:
Use the /force option with the tf merge command. If there is a changeset that was previously merged (perhaps incorrectly) and you want to merge it again. The /force flag ignores merge history that indicates a particular changeset was previously merged from source to target, and merges the changeset again.
Undo the previous merge using Rollback. If you've recently done the merge in which changesets have been discarded. Find it in the history, rightclick the changeset and pick Rollback and check in the code that has been undone.
One of my projects in TFS keeps displaying changesets as unmerged between the branches after I have already merged and committed them. I used the Track Changeset feature and clicked the Visualize button to see if the change was merged. It shows that it was merged but has a different background color and an asterisk. I checked the help and it gives this explanation:
If a branch has received some (but not all) of the changes in a changeset, the branch is filled with a pattern, and an asterisk follows the changeset numbers within that branch. For example, the previous illustration shows that only some of the changes in changeset 38 were merged to the Test branch
Track Changes Help
I don't understand how it is that I only partially merged those changesets. Perhaps I did not have latest when I completed the merge but it is happening to a lot of the changesets and this only happens on this one branched project folder.
Is there a way to find out what did not get merged and merge it so that the changesets will quit showing up as a merge candidate?
A partial merge is recorded when only some changes from a changeset are merged into the target. There are two common scenarios in below which you can end up with partial merges:
Scenario 1:Undo some pending changes when you are checking the merged files
In this case, even though we already merged changeset Dev to Main, it is still a merge candidate. This is caused by the fact that the merge engine detected that there are still some changes in that changeset which were not propagated from Dev to Main.
Scenario 2: Performed the merge at feature level not from the top of the branch
For example: consider that you have two branches Main and Dev, each of them has two folders (Feature1 and Feature2) and each feature folder contains one file. We edit both files from the feature folders (Dev\Feature1\feature1.txt and Dev\Feature2\feature2.txt) and check-in the changes.
If you perform the merge operation at the Feature1 level.（Changset142→
Changeset143） You will notice in the Pending Changes window that only the edit done in the Feature1 folder will be merged. Complete the merge.
If you take a look at the merge history of the Feature1 folder you will see that all changes from changeset 142 have been merged into changeset 143.
However,if you take a look at the merge history of Main you will see that only parts of changeset 142 have been merged into changeset 143. This is normal as changeset 142 has some changes – the edit of the file in the Feature2 folder – which were not delivered.
In case of a partial merge, to figure out what changes have been merged and what changes from the changeset were left out. The only way to achieve this is to diff the contents of the changeset that was partially merged, and the contents of the changeset that was generated as the result of the merge. More detail info you can refer this blog: Partial Merges in TFS – A Guide
Update
You can do a discard
merge.
This has to be done from the command line. Open up the Developer
command
prompt,
then navigate to a folder under either of your branches (i.e. navigate
to one of the affected
workspaces).
Then type:
tf merge /r /discard "$/Project/B1" "$/Project/B2" /v:C12345~C12345
This will take the changeset identified (in this case it was changeset
#12345), and update it as merged to the target branch (branch B2). The target files will be checked out, but they will not be changed - you
can simply check them in to complete the operation. After that the
changeset will no longer appear as a merge candidate. You can specify
a range of changesets to merge at the same time, but they should be
contiguous.
Note that after doing this a changeset will occasionally still show up
as a merge candidate - this is rather uncommon with the latest
versions of TFS, and it is virtually impossible to fix (unless you are
running your own local install of TFS and want to get your hands very
dirty in the database). If you end up with one of these marooned
changesets, just ignore it.
Source:
Finding merge candidates in TFS
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".