I just migrated a team of 7 developers from VSS to TFS. I migrated all of their code into a DEV folder which I then branched into a QA folder (which I branched into a PROD folder). The developers usually don't work on the same files, but there are some shared utility classes. All of the code is for a large ASP.NET web site. When the developers are ready to merge from DEV to QA, they only want to merge their changes. For example, let's say that Developer1 has been working on a project for the last 3 months and he's ready to merge all of his code into QA. However, Developer2 has been working on a different project for the last 2 months which is not ready to be merged. Developer1 and Developer2's changes are not in any way dependent on each other, but they are not separated into different folder structures and they each regularly do a get latest. There doesn't seem to be a way for developer1 to only merge his changes without also merging all of developer2's changes. Currently, developer1 is going through the Pending Changes window and 'Undoing Pending Changes' for all of Developer2's changes, but this is time consuming. They could merge each file individually, but this is also time consuming. Is there an easier way? I am going to have a coronary if I hear one more person explain how much easier it was to work in VSS.
It sounds like the best strategy (going forward) is to branch-on-project. If Dev1 and Dev2 are working on fundamentally different things, they should each have their own branch of the code.
Keep in mind that everything in TFS is stored as deltas and pointers, so you aren't massively increasing the size of your repository by doing this. Until the file changes, the new branch is only a pointer to the original file, then when the file is checked in, only the delta is stored.
In your current situation, you're doing what's called a "cherry-pick" merge. This is not a fun thing to do (as you are finding out), and it is prone to PEBKAC errors. For this reason, cherry-pick merges are strongly discouraged. However, if you do need to do cherry-pick merges, you can put some control around by merging by changeset (instead of latest).
To do this, identify the changesets that Dev1 has checked into your Dev branch, then merge those changesets into your mainline branch. You'll need to do it in order from oldest to newest to be sure to get all of the files. Your best bet, if you are going to do this, will be to either write a utility to do it, or move down to the TF.EXE command line, so you can batch your merges together.
Remember to do your merges in a clean workspace, and you can batch up all of your merges before you check in.
The key lesson you are learning here is that your branching strategy/methodology is one of the most important things about SCM (in general). We migrated from StarTeam to TFS a little over a year and a half ago, and when we did, we spent approximately 4 months revising our branching approach until we came up with something that fit our environment and our development processes.
Is there a reason that they seem to be branching all changes instead of just their own changesets?
The merge dialogue specifically asks whether you want to branch "all changes up to a specific version" or "only specific changesets." If you choose the latter then you can cherry-pick your changes and don't need to take everyone's code. Assuming each dev is working on a non-overlapping set of files, this isn't something that should be causing you problems.