For some unknown reason, TFS seems to keep queuing certain files for merges, even though there are no changes. In the Pending Changes windows, the Change column only states Merge, and not the usual Merge, edit or Merge, branch.
Nobody touches these files and yet they keep reappearing under the pending changes merge queue.
I've seen this happen before with a folder that was deleted, but kept reappearing in the merges between branches. In that case, I used tf destroy in all branches for that folder's path and it solved the problem. However, in this environment, it's with files that the team wants to keep.
Has anyone else experienced and/or resolved this issue?
Try TFS 2010 SP1 and CU1. It fixed some merge bugs. Like the following:
Merge or discard in both directions cause unnecessary "empty" merges
in future merge attempts.
If you have the Team Foundation Power Tools installed you can use tfpt uu to undo changes to any unchanged files (yes, it's well annoying when files are flagged as changed and you get told they are identical!).
Related
We have a branch called "Main". In July 2012 I created a new branch from this called "Phase 3" for the next version of our project. We have been working on this since then, but from time to time some other changes get applied to Main.
In May this year we performed a merge from Main to Phase 3 with some of those changes, and that was all fine.
Between then and now, we upgraded our TFS server from 2008 to 2012 update 3. (I wasn't involved with the "upgrade" but I believe it was an install on a new server with some kind of backup/restore of the data.) We've bit had any other issues with this.
Last week I tried to perform another merge from Main to Phase 3. I chose "selected changesets" because we have done a serious amount of rework in our phase 3 branch so merging changes across is quite difficult - so I wanted to do them bit by bit.
However, I was surprised to see that Visual Studio was trying to merge across changes from July 2011 - a good year before the branch was made (the very first changes made to this part of our project in fact.)
Oddly enough, if I view the history of the phase 3 solution I can expand it and see all these changes. So TFS appears to know that they have already applied.
I tried to merge some of the earlier changes across to see what would happened. The only changes it included were to do with items that had been renamed or deleted. For example, we had renamed our solution so TFS wanted to branch and merge a copy of the SLN with the old name. Or we had some images that had been subsequently deleted in both branches, but not at the time of this new merge.
So I backed this out and tried to merge everything across from May this year - i.e. just before our last merge across. This carried over a hideous number of changes - all sorts of things including regular merge/edit type changes. So I backed that out too!
We had created another branch from Phase 3. I have been able to merge between the two branches OK. I think it was created about a week before the TFS upgrade. But it's not experiencing the issue.
We have other branches that were taken from Main. These are experiencing the issue in that TFS is wanting to apply changes that it has already made.
I am using VS2012 update 3 to do the merge. I also tried VS2010 just in case but that does the same. Also a colleague has tried it and confirmed the same symptoms.
I don't think it helps that our phase 3 is so vastly different to main that merging anything across is really difficult.
Does anyone know how I can best resolve this? I'm a little worried about doing something I might regret later on!
I encountered similar problems when upgrading from TFS 2008 to TFS 2010. The issue is probably due to partially merged changesets. I.e. some of the files in the changeset have been merged, some haven't. Or it could be a branch move / rename situation. See the answer here for details of why a branch rename can cause this problem
In TFS 2008 if you attempted a merge, then unchecked files from the pending changes list. TFS assumed that you didn't want to merge the file ever again and on subsequent merges you wouldn't see those files.
In TFS 2010 or higher, the behaviour changes. If you uncheck files from the pending changes, on the next merge TFS will attempt to merge those files again. I think TFS 201x has the correct behaviour but its a pain that MS didn't highlight the change in behavior.
To check if this is the case, run the following from the command line
tf merge $/tp/main $/tp/phase3 /recursive /candidate
The /candidate switch tells TFS to give you a list of changesets it wants to merge without performing the merge. If you see any changesets in the list that have a * next to them, these are partially merged.
To fix it you have 2 choices.
Merge the files and resolve the conflicts, it might be worth merging on a changeset by changeset basis rather than trying to do them all at once. This will probably be a bit painful but once it's done it's done.
If you're confident that the phase 3 branch is correct then you can Merge using the command prompt. If you use tf merge $/tp/main $/tp/phase3 /version:c123~c456 /recursive /discard where c123 represents the oldest changeset you want to ignore and c456 represents the most recent changeset you want to ignore. The /discard switch tells TFS to update the merge history so that it thinks the merge has been done, but it won't actually perform the merge. This should remove the partially merged changesets from your list of candidates
If you opt for option 2 then you should do some analysis to make sure that you really don't want to take the partially merged changesets.
If you get to the point where merging is too difficult, or you just don't trust it.. then the only practical option is the "stomp over it with a new changeset". ie - do the merge manually outside of TFS and then commit your new, fixed changeset. then, kill the old branch and start again.
Not an ideal situation to be in, but your source integrity is paramount. Hopefully starting from a fresh branch will prevent issues like this in the future.
Yes this is one of the Doh! Damn! I shot myself in the foot. I don't have a lot of experience with TFS in large teams, but I'm facing this issue.
During a transition to new equipment, a developer forgot to check-in some code. Work proceeded on the new laptop for several weeks before noticing that the previous work was not checked in. Mutliple check-in have occured.
I have recovered the files from the old laptop, and have them on my current laptop. What is the best way to merge in these changes? Do I create a branch, merge in these changes, and then rejoin the branch?
Is there a "cookbook" out there that details what should happen when faced with various situations?
We are using TFS 2010.
Thanks in advance...
Creating a branch here is probably a little bit heavier-weight than what you need for this one-off situation. If it were me, I would do this:
Set up a workspace on your computer with the appropriate mappings.
Do a Get Specific Version to the version that the other computer was at. The best case scenario is if the user never deleted their workspace on the server. Then you can simply specify their workspace as the version and you'll get the files as they existed on the laptop. (You can specify this as Wworkspacename;owner name.) If the user deleted their workspace, you can get based on the changeset number they were at, or based on the date they were working at.
Copy the recovered files on top of the new TFS workspace.
Run tfpt online from the Team Foundation Server Power Tools. This will examine the local filesystem against the server and determine what changes were made. You may wish to examine the options, notably the /diff flags (which performs MD5s on the file instead of simply examining the readonly bit), and the /deletes and /adds flags, which detect deleted and add files, respectively.
Do a Get Latest on your workspace, resolve any conflicts, and check in.
You can follow this sequence to try out:
Make a merge-branch of your code version based on the time-stamp of where your restored laptop code has left the version control system.
Get your branched code to a location on disk.
Perform a check-out for edit of the entire workspace.
Copy the old restored code over the files in this workspace.
Perform a checkin of the local code into the branch.
Merge your latest code (main trunk) into the branch, merging changes, solving conflicts.
If all build and tests out correctly on the merge branch, merge that branch back into the main.
That should do the job.
I have a feeling this is a very stupid question, but I can't find the answer anywhere.
So we have a Dev branch and a QA branch. I merge a bunch of contiguous changesets from Dev into QA, and resolve conflicts. Now I want to merge in a later changeset, over the changes I just merged (not having checked in the changes from the first merge). No dice, says TFS:
The item $/My/Path/to/the/file.vb has an incompatible pending change.
What's its problem? Why won't it give me a merge conflict option to merge the new changeset to the files with the pending changes? I don't want to check in the first merge just so I can merge in another changeset.
TFS doesn't allow you to merge multiple non-contiguous changesets if the same file is changed in both of them. Your best option is to checkin the first set of changes, then do the merge.
I had the same problem. I did undo all the pending local changes and un-shelved the pending changes. It fixed my problems.
I was experiencing this same issue for a different reason and since I stumbled here for help I will give my solution.
I had a branch (branched_from_main) that was branched from main. I made changes to branched_from_main and checked them into the tfs repo. Then when I tried to merge branched_from_main back to main I was experiencing this issue. After looking into it for a while I realized that I had opened the main solution and built it. This meant that the solution now pulled down all of the nuget packages. Thus my main branch was considering the packages as pending changes.
So to fix the issue I had to reopen the main solution and undo those pending changes. Then I was able to merge branched_from_main back to main.
It is enough to check-in the folder that you are going to branch to.
In my case I created a new folder in my target branch and it was on the "Add" state (without check-in) and I had this same problem. After I checked in this folder it worked well.
When I merge files from one branch to another and then go to check in files into the target branch, there are MANY files checked out, just the ones that changed. For example, Main and Critical branches were the same and we made changes to only 2 or 3 files on the Critical Fix branch. I then merged Critical ==> Main, and when I went to check in changes to the Main branch I noticed that there were numerous files checked out, not just the 2 or 3 that were actually changed in the Critical Fix branch. Moreover, when I compare a file from the Main branch to one on the server, I am told that the files are identical. If the files are identical, why are they checked out? Any help would be appreciated, or even a link that explains how TFS 2010 does merges.
The default Source Control Merging tools in Visual Source Safe and then TFS have always been rather poor - they are often confused by the simplest changes, often detect identical files as being "changed", and the auto-merge facility frequenty fails (includes the wrong changes). I quickly learned distrust for these merge tools (in about 1995) and have not seen any evidence in any of the new releases since then that the core merge algorithms have been improved at all.
The good news is that you can replace the client-side merging tools with third party ones (I use one that works so well that I actually trust its auto-merge option. I once spent 2 days trying (and failing) to do a complex merge with the TFS tools and in the end bought this 3rd party tool and re-did the entire merge successfully in 15 minutes!)
The bad news is that the first step of branch merging just uses the TFS merge code, and so it gets confused a lot, resulting in the symptoms you've described. This is frustrating in such a key feature of such an expensive application as it wastes a lot of programmer time on every merge to fix imaginary "conflicts" - on the plus side, with the help of 3rd party tools it is usually very easy to reliably resolve these merge issues.
I have had the same problem. I created a branch of our DEV branch and made changes to a few files. I checked in my changes and merged the latest changes to DEV into my branch. After the merge all 30,000+ files in my branch were marked as changed. Just like cju, I found that a comparison of most of the files showed that no changes had been made.
I decided to undo all changes and try again. When I right-clicked on the solution and selected Undo, I got a message that one file had changes, was I sure I wanted to undo that file? I clicked "No to All" and when the undo operation was complete, only the files that had been changed during my merge from DEV were still checked out. This was exactly what I wanted so I checked those changes into my branch and continued working.
I hope others can correct their situation as easily as I was able to.
One thing I noticed is that when one file is changed in different branches resulting in exactly the same content, then merging marks it as a conflict since the file is changed in both places. Of course a difference view of the file notices that there are no changes and therefore an auto merge solves this automatically for you.
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.