TFS 2013 Merge Tips

We did our first team merge last week.  There were several things we learned about doing merges of your whole branch.  Below are some of the learning's and any helpful links we came across for our next merge.

White-space

At some point one of the developers ran an application that reformatted the code.  In doing so it removed extra white-space in various places.  This caused a large number of files to not automatically resolve and where presented as conflicts.  We are not sure why but since the white-space was different on both branches this flagged the file.

This article found on stackoverflow.com was detailed enough to show us how to get around this however the code would be different between trunk and the branch.  The right thing to do would be determine which format was correct and accept the files on that branch.  In our case it was the source branch so we went through the several hundred files and accepted source version for those.

Ignoring Folders

There is folder we call Global that has files global to all solutions (files in the folder are references by each solution or project).  There are also build scripts in it managed by my team.  We do not want the developers to attempt to merge these folders without my team reviewing the changes.  Once we had a developer change a global file not knowing what global meant and a bad change was propagated to all solutions.  This caused confusion and delay.

You could have the team doing the merge ignore the folder by using the command-line and using the /discard parameter.  This is where I found that on stackoverflow.com.

We decided on another path.  With TFS source control permissions we can set it so that the teams cannot merge certain folders and/or files.  So when they do the merge it will give a permission error and not attempt to merge it.  This way they don't have to remember what to discard.  The other benefit is if they want to modify a global file it will have to be reviewed and changed by the build team.

Merge vs. Edit

During the merge session the pending changelist was still quite large.  They team was worried that builds would be kicked off by the system for allot of applications that had no changes between the branches except for files that we ignore.  What we noticed in the pending list were two key words.  Some files just had a merge and some had merge,edit next to them.  Doing some digging the merge means it is just creating a merge record but not checking in a new version of the file at the destination.  While merge,edit has both a merge record being created and a new file version being checked in (which will trigger a build).