TFS Simple Merge Issues

It seems as though my scenario is about as simple as it can get. I have Main and a branch called Dev. I picked a directory in Dev that has only my code and did a Merge (based on all changesets up to a specific changeset.

First question, does it immediately checkin the merge, or I should do a checkin right after that? I ask because of these messages, I saved them in notepad, but didn't write down exactly what I did. The conflict is because of a change in directory structure.

Changeset 322 successfully checked in.

Deleting C:\SourceEagleConnect\Main\BizTalk\ACH\Sample\Sample1.sln TF14119: Cannot merge a delete of $/EagleConnect/Dev/BizTalk/ACH/BizTalk to $/EagleConnect/Main/BizTalk/ACH/BizTalk because one of its children has been renamed or moved. TF14121: The changes previously made to $/EagleConnect/Dev/BizTalk/ACH/Sample1/Sample1.sln that have not been merged will be discarded by merging the deletion of $/EagleConnect/Dev/BizTalk/ACH/Sample1/Sample1.sln. TF14119: Cannot merge a delete of $/EagleConnect/Dev/BizTalk/ACH/BizTalk to $/EagleConnect/Main/BizTalk/ACH/BizTalk because one of its children has been renamed or moved.

The 'ACH' project is really not the one I'm concerned about, it's files in other projects that are critical.

I then used a compare tool to compare the disk of Dev and Main, and I see many files in Main that don't have the changes from Dev.

On one specific file, I did the following analysis. I did "view history" in both Dev and Main, then I ran from the command line "tf merges Dev/file Main/file".

View History Dev shows:

213 edit    nwalters    8/6/2010 2:43 PM    New Host Names based on application instead of adapter 
159 edit    nwalters 开发者_StackOverflow中文版   7/20/2010 10:16 AM  BTDF - reset to use new SettingsFileGenerator.xml, improved to handle new EagleConnectConnectionString 
50  branch  nwalters    6/22/2010 10:04 AM  Original checkin of "Dev" Branch

View History on Main Shows:

323 merge, edit nwalters    9/23/2010 2:02 PM   BizTalk-Only Merge 09/23/2010 (there were some ACH warnings) 
175 merge, edit nwalters    7/27/2010 2:29 PM   Check-in after big merge of all BizTalk from Dev to Main 
49  add nwalters    6/22/2010 10:00 AM  Original checkin of EagleConnect source cod to TFS

"tf merges" shows:

Changeset Merged in Changeset Author                           Date
--------- ------------------- -------------------------------- ----------
     159                  175 nwalters                         7/27/2010
     213                  323 nwalters                         9/23/2010

So it looks like changeset 213, the change that is "lost" was included in the 323 merge. Yet when I look at the Main source code, it is not there (its not on disk, and if I do a "view" [from history in source explorer] it doesn't appear to be in TFS either).

When I do a merge now, it says "nothing to merge".

Regarding your first question, a TFS merge from a Source branch to the Target branch does NOT automatically check-in the merge changes into the target branch. The way TFS merge works is - assuming you used the Latest Version option to merge:

1. it compares the history of changesets in the target branch and determines what changesets from the source needs to be merged into target.

2. it copies the SERVER version of the changesets of the Source branch to the LOCAL version of the Target branch (this gives you the opportunity to build your local target with these changes and ensure it does not break your existing build before you check it in.)

3. once you are satisfied with the merge changes in the LOCAL of the Target branch, you need to manually check-in these changes to the Target branch.

Hence before a merge, you always need to get the latest version of the Target branch to your local.

I did a get latest on another machine, and the code matched perfectly (disk compare of Dev to Main). So I'm working through now, apparently each item that doesn't match is caused by one of the following:

1. It was changed outside of TFS
2. It was never checked into TFS (some I forgot to check-in, others were bin/debug type files that will not be checked-in).