34

We've had this happen more than a few times were we consider it to be more than a fluke at this point. When we are merging back after we are complete with our branch there are way more changes then their should be. So most of the files showing as pending changes never changed (in most of the cases in neither the branch or the base). When i compare them (i use beyond compare) there are no differences. I haven't went through all the files that didn't change but in most cases it seems like they are marked as [merge] and the files that actually changed are marked as [merge,edit].

In one case we probably changed around a 100 files it pending changes showed more than 22,000 changes. We tried checking them in at one point thinking tfs would be smart enough to know what files changed and which didn't. But it checked in all files. Does anyone know whats going on and how to fix it?

We are running TFS 2012 w\ Update1
Everyone is using Visual Studio 2012 w\ Update 1.

coding4fun
  • 8,038
  • 13
  • 58
  • 85

5 Answers5

40

For anyone having the same issue a work around is to undo your pending changes. When you get the confirmation dialog choose "No to all". Only your pending changes should be left.

coding4fun
  • 8,038
  • 13
  • 58
  • 85
  • 2
    This is the case I'm getting constantly with TFS2012 and TFS2013. Your solution worked great! – Szymon Seliga Dec 13 '13 at 15:58
  • 9
    This works when you only have changes to files. It will not merge any NEW files that you have added. – Mark Hosang Aug 29 '14 at 02:21
  • 4
    Yes - make sure when selecting the files, you do NOT select newly added files as they will be removed from pending changes. – Mladen Mihajlovic Sep 01 '14 at 09:32
  • The dialogue to do this is insanely slow - ~1s+ per change (and I have 25k). And of course, it reverts any changes made if you cancel it halfway through. – fastmultiplication Apr 13 '16 at 01:13
  • Thanks. This worked for me when "tfpt.exe uu . /noget /recursive" failed. I tried many other suggestions first (e.g., ensuring I was in a mapped folder; ensuring merge source/target branches hadn't been renamed at some point; reinstalling TF Power Tools) without success. I suggest shelving your changes first in case the process hiccups. – Richard II Oct 26 '16 at 14:03
25

Regarding the problem where you had changed 100 files and TFS wanted to merge several thousand. This is usually caused by renaming (or deleting and then un-deleting, or moving) a branch. This has bitten me a couple of times and I feel your pain.

The best advise I can give is, once you've created a branch, leave it alone. Don't move it, don't rename it. If the location or name of the branch are wrong, live with it until it's time to delete the branch and create a new one.

Because of the way TFS 201x work behind the scenes, changing the root folder of a branch effectively turns it in to a different object. When you try to merge the branch again, TFS will perform a baseless merge which effectively means that it appears that all files in the branch have changed (even though they haven't) This is new behaviour, older versions of TFS (2005 / 2008) don't suffer from this problem.

e.g. you have a Team Project that looks like this

$/TeamProject/Main

You then create a branch from "Main" called "Dev"

$/TeamProject/Dev

You can merge as much as you like and there shouldn't be any problems. Then you decide that the folder structure might get a bit messy when you have several dev branches so you create a folder called "Development" at the root of the team project and move the dev branch in to this folder

$/TeamProject/Development/Dev

OK now behind the scenes the move is a rename and a delete, the old dev branch still exists under $/TeamProject/Dev (you can see this by going to "tools", "options", "Source Control", "Team Foundation Server" and then check the setting that says "show deleted items in Source Control"

The folder called $/TeamProject/Development/Dev is actually a brand new thing! Therefore it doesn't have a merge relationship with "Main". Confusingly though the IDE will show a relationship, but really it doesn't exist. The first time you merge from $/TeamProject/Development/Devto $/TeamProject/Main TFS will perform a sneaky baseless merge to establish the branching relationship.

The same thing happens if you rename a branch (the old branch will be deleted and a new branch will be created under the covers)

This Blog goes in to some more detail

Community
  • 1
  • 1
James Reed
  • 13,873
  • 51
  • 60
  • thanks. That seems to be it. I know 4sure one of the branches was moved b4 trying to merge. The current one i'm not sure but thats probably it. – coding4fun Mar 26 '13 at 17:07
10

The comment above with the "No to all" option in the undo confirmation dialog works okay, but as commented by Mark Hosang, this will not work right if you have new files. Mladen Mihajlovic is right that you can make sure to not select those new files. However with a large code base, wading through this is very tedious.

So my method: before getting to the confirmation dialog, you are presented with a window to select which files to undo. This window has sortable columns. You can sort by the Change column and select only the files with merge status (these are the unchanged files; merge, edit are edited files and merge, branch are new files). Just click Undo Changes with just those selected, and then enjoy the beauty of an uncluttered merge changeset.

Example

broken-e
  • 790
  • 7
  • 10
7

Try this:

  1. select all pending files
  2. on context menu click 'Undo...'
  3. in the 'Undo Pending Changes' dialog sort files by 'Change' column
  4. deselect all files except 'merge' using shift+click
  5. click button 'Undo Changes'
WURMi
  • 109
  • 1
  • 2
0

From my experience this happens when TFS has no relationship between file A in branch A and file B in branch B.

When merging branches TFS always creates a relationship between the files when no relationship is present already. Hence it wants to check in as "merge" to remember these relationships.

I tend to undo these "merge" changes when i don't need the relationships (e.g. for reparenting).

ViRuSTriNiTy
  • 5,017
  • 2
  • 32
  • 58