Team Foundation Server - Previously merged changesets reappear in merge wizard

Question

Our SCM structure is the following:

Main
 |--Release

Developers check in to main. When we want to release, we cherry-pick merge changesets from Main to Release, test and run our deployment build which builds and deploys the application and labels the release branch as such.

To merge, I would, using the Source Control Explorer, right click on 'Main' > Branching and Merging > Merge. Choose 'Selected Changesets' There is only one Target branch (Release). Select the changesets, test locally, check in to Release. This has worked fine for months.

However, today some very early changesets have just 'appeared' in the Source Control Merge Wizard, at the top of the list. But bizarrely, not all of them.

The equivalent CLI command is

tf merge /candidate /recursive [source] [destination]

This command returns the following list:

   3* Person.One      27/11/2009
  43* Person.Two      21/12/2009
  50* Person.Two      22/12/2009
  54* Person.Two      22/12/2009
  57* Person.Two      22/12/2009
 114* Person.One      12/01/2010
 116* Person.One      13/01/2010
 128* Person.One      15/01/2010
 138* Person.One      19/01/2010
 139* Person.One      19/01/2010
7846  Person.Three    19/01/2012
7847  Person.Three    19/01/2012
7848  Person.Three    19/01/2012
7849  Person.Three    19/01/2012
8030  Person.Four     31/01/2012
8031  Person.Four     31/01/2012
8032  Person.Four     31/01/2012
8045  Person.Five     01/02/2012
8050  Person.Four     01/02/2012
8052  Person.Six      01/02/2012
8053  Person.Six      01/02/2012
8054  Person.Three    01/02/2012
8055  Person.One      01/02/2012
8056  Person.Seven    01/02/2012
8057  Person.Five     01/02/2012
8058  Person.Six      01/02/2012
8059  Person.Five     01/02/2012
8060  Person.Five     01/02/2012
8063  Person.Five     02/02/2012
8068  Person.Five     02/02/2012
8069  Person.Eight    02/02/2012
8070  Person.Five     02/02/2012
8071  Person.Five     02/02/2012
8072  Person.Five     02/02/2012
8073  Person.Three    02/02/2012
8074  Person.Three    02/02/2012
8077  Person.Seven    02/02/2012

The only 'clue' is the asterisk which I believe means that a partial merge has already been completed.

I'm totally stumped by how this could happen. No administration has gone on on the server. It has happened within the last 6 hours or so.

If I attempt a merge in my workspace, I get no conflicts, and, well, i'm not really sure what would happen if I checked in. Obviously the files and structure have changed a lot over two years!

I can use the tf merge /discard command to 'make them go away' but I would like to get to the bottom of why it happened, for my own curiosity if nothing else.

TIA

Update:

I elected to 'discard' the changesets that had appeared using the following command:

tf merge /discard /recursive [source] [destination] /version:C3~C139

This resulted in a selection of pending changes in my workspace, which I duly checked in.

Unfortunately, if I run

tf merge /candidate /recursive [source] [destination]

I now have even more historical changes 'awaiting' merge, including the ones I tried to discard in the first attempt:

   3* Person.One        27/11/2009
  43* Person.Two        21/12/2009
  50* Person.Two        22/12/2009
  54* Person.Two        22/12/2009
  57* Person.Two        22/12/2009
 114* Person.One        12/01/2010
 116* Person.One        13/01/2010
 128* Person.One        15/01/2010
 138* Person.One        19/01/2010
 139* Person.One        19/01/2010
 140  Person.One        19/01/2010
 141* Person.One        19/01/2010
 142* Person.Two        19/01/2010
 149* Person.Two        20/01/2010
 152* Person.Two        20/01/2010
 160* Person.Two        21/01/2010
 161* Person.Two        21/01/2010
 165* Person.One        21/01/2010
 167* Person.Two        22/01/2010
 173* Person.Two        22/01/2010
 199* Person.Two        27/01/2010
 200* Person.One        27/01/2010
 203* Person.Two        28/01/2010
 204* Person.Two        28/01/2010
 205* Person.Two        28/01/2010
 206* Person.Two        28/01/2010
 208* Person.Two        28/01/2010
 213  Person.Two        28/01/2010
 215* Person.Two        28/01/2010
 235* Person.Two        01/02/2010
 238* Person.Two        02/02/2010
 241* Person.Two        02/02/2010
 259* Person.Two        04/02/2010
 262* Person.Two        04/02/2010
 264  Person.Two        05/02/2010
 296* Person.Two        10/02/2010
 309* Person.Two        11/02/2010
 316* Person.Two        12/02/2010
 317* Person.Two        12/02/2010
 320* Person.Two        12/02/2010
 338* Person.Two        15/02/2010
 353* Person.Two        16/02/2010
 365* Person.Two        18/02/2010
 394* Person.Two        22/02/2010
 399* Person.One        22/02/2010
 400* Person.One        22/02/2010
 401* Person.Two        23/02/2010
 403* Person.Two        23/02/2010
 404* Person.Two        23/02/2010
 405* Person.Two        23/02/2010
 424* Person.One        25/02/2010
 426* Person.Two        26/02/2010
 444* Person.Two        02/03/2010
 445* Person.One        03/03/2010
 461* Person.Two        08/03/2010
 476* Person.One        10/03/2010
 477* Person.One        10/03/2010
 478* Person.One        10/03/2010
 501  Person.One        12/03/2010
 502  Person.One        12/03/2010
 503  Person.One        12/03/2010
 504  Person.One        12/03/2010
 506  Person.One        12/03/2010
 511* Person.One        12/03/2010
 515* Person.One        15/03/2010
 517* Person.Two        15/03/2010
 518* Person.One        15/03/2010
 522  Person.One        16/03/2010
 523  Person.One        16/03/2010
 538  Person.Two        17/03/2010
 539  Person.Two        17/03/2010
 540  Person.Two        17/03/2010
 543  Person.One        17/03/2010
 581* Person.Two        18/03/2010
 582* Person.Two        18/03/2010
 644* Person.Two        26/03/2010
 706* Person.One        30/03/2010
 918* Person.One        13/05/2010
1594* Person.One        15/07/2010
1601* Person.One        16/07/2010
1626* Person.Three      20/07/2010
1627* Person.Three      20/07/2010
6153* Person.One        17/08/2011
7691* Person.Four       11/01/2012
7846  Person.Four       19/01/2012
7847  Person.Four       19/01/2012
7848  Person.Four       19/01/2012
7849  Person.Four       19/01/2012
8030  Person.Five       31/01/2012
8031  Person.Five       31/01/2012
8032  Person.Five       31/01/2012
8050  Person.Five       01/02/2012
8054  Person.Four       01/02/2012
8073  Person.Four       02/02/2012
8074  Person.Four       02/02/2012
8104  Person.Six        03/02/2012
8110  Person.Six        03/02/2012
8112  Person.Seven      03/02/2012
8113* Person.Five       03/02/2012
8114* Person.Five       03/02/2012
8127  Person.Seven      06/02/2012
8128  Person.Seven      06/02/2012
8130  Person.Eight      06/02/2012
8135  Person.One        06/02/2012
8138* Person.Five       06/02/2012
8140  Person.Five       06/02/2012
8142  Person.Five       06/02/2012
8143  Person.Nine       06/02/2012
8144  Person.Nine       06/02/2012
8145  Person.Ten        06/02/2012
8146  Person.Eleven     06/02/2012

I really have no idea what has caused this to happen. Any advice appreciated.

Answer 1

You are correct, the "*" means that some files in changset 3 have been merged in to "release" and others haven't. This is usually caused by un-checking files in the pending changes window when merging.

Have you recently upgraded from TFS 2008? We had the same situation after our upgrade. In TFS 2008 if you unchecked a file from a merge checkin, TFS assumed that you never wanted to merge that file ever ever ever! The only way to pick up the unchecked files was to drop to the command line and use tf merge /force

In TFS 2010 the behaviour has changed and now if you do a partial merge TFS will always remind you that there are outstanding merge candidates in a partially merged changeset.

You can do 2 things.

1. Merge the changesets (it's unlikely that you want to do this given the length of time that has passed)
2. use the command tf merge /recursive /discard /version:C3~C139 [source] [destination] This will tell TFS that you want it to think it has done the merge even though it hasn't

Answer 2

We determined that the reason for this behaviour was that a previously deleted file had been 'resurrected' in the Main branch, in the sense that a new file was created with the same name.

When this happened, all previous changesets which had this file in them reappeared in the merge dialog as partial changesets.

A full merge seemed to resolve the issue.