I have recently discovered that I was using my third party diff/merge tool incorrectly when resolving conflicts encountered merging from the trunk to my team branch. As far as I know, only files that were merged in the merge tool were affected. I know how to use tf merge /force to re-do a merge, but I don't want to re-merge every file if I can avoid it, just the ones that I had to merge manually. Is there any way to get a list of such files now, long after the merge changesets have been checked in?
Unfortunately, TFS does not track any data about which files were resolved using a merge tool. Whether a file was merged manually or automatically it is still just recorded as a "merge" in TFS.
Related
Maybe its a confusing title but the scenario is this one - we have two branches; DEV -> QA. When tests are done people merge their changesets from DEV into QA one by one. All fine. The strange thing is that a small number of merged changesets are appearing in Merge wizard when we attempt to do reverse integration QA -> DEV. If I pick one for the merge, pending change shows that files are checked out with an 'merge,edit' tag but when compared to latest there are no differences.
Obviously we need to fix this since the list keeps getting longer and longer. But, I would like to understand why is this happening in the first place. Then, how to fix this situation.
We're using TFS 2015 server and Visual Studio 2015. No 3rd party tools.
Thank you for reading.
When you want to merge back, the changeset reappears is because when TFS does a merge, it bases the merge on prior merge history, not on the actual contents of the source and target files.
If you have such request, you can use tf merge /discard command to update the merge history, which does not perform the merge operation. This discards a changeset from being used for a particular merge.
https://learn.microsoft.com/en-us/azure/devops/repos/tfvc/merge-command?view=azure-devops
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.
I'm taking code from a 3rd party, and modifying it. The 3rd party puts out occasional releases, as a zip file, I want to keep my branch, stored in Team Foundation System, up to date with theirs. But I don't see any point of keeping their main trunk in my source control, just so I can merge it into my branch. Is there any way I can just do some kind of baseless merge from their files I download into my TFS branch?
I tried this:
tf merge /baseless "C:\localpath\to\third-party-release-2.0" "C:\localpath\to\mybranch"
and this:
tf merge /baseless "C:\localpath\to\third-party-release-2.0" "$/serverpath/to/mybranch"
and both tell me
No appropriate mapping exists for
C:\localpath\to\third-party-release-2.0.
The merge command applies changes from one branch into another.
According to your command, you are trying to merge something from local to your server branch. This is not supported in TFS. You may need to check in your C:\localpath\to\third-party-release-2.0 into TFS source control first. More info about tf merge command from MSDN.
I recently moved from a svn shop to one that uses TFS. One of the issues I'm having in using the TFS merge is ignoring files. Our branches have several files that we never want to merge(version info, ivy files etc) and we have to manually uncheck them each time we run a merge. I know in SVN there is a file property you can set to ignore files during a merge, does TFS have anything similar?
Thanks in advance
From the command line, you can use something like the following:
tf.exe merge /discard <path to the file to exclude>
That will update the merge history as if the file had been already merged, so it won't continue appearing in the merge candidates list.
Our project has hit a point where we need to split off some code into a separate team foundation project. We would like to move these files so they retain their version control history. Temporarily we are copying the files back to the original team foundation project and re-adding them just so that our daily build & test process doesn't break. As we are able to modify our build & test process we will start to remove these temporary copies.
One issue we are noticing is that we have a nightly script that checks various maintenance branches to see if there are changesets that haven't been merged back to trunk. It is now whining about changesets that have been merged before. These changesets seem to be related to the files that have been moved and re-added. Any ideas as to why we are seeing this and how we can discard these merge candidates? If we do a merge /discard TF tells us "there are no changes to merge". It seems to be confused. Also are there other problems we might run into with this approach? Perhaps there is a better approach?
The solution that I found was to merge /discard all other changesets, then do a "catchup" merge /discard i.e. not specifying any version info. This generated a number of merge related pending changes but when I went to check them in, I got a TF14088 error. The workaround for this error was to checkin just the problematic files/folders first and then check in everything else.