• Move to Folder – Allows multiple items to be moved at once in SCE
• Branch to Folder – Allows multiple items to be branched at once in SCE
• Drag & Drop – Adds drag and drop support for Move, Branch, and Copy operations
• Show/hide deleted items – Quick way to toggle the “show deleted items” option
• Destroy – Enables the Destroy command inside of VS

There are a few other cool features as well, but the ones listed above are some that I’ve heard people ask for in the past.  Check it out here: https://visualstudiogallery.msdn.microsoft.com/c6642e7f-1a58-4ff0-aef9-0322dcc2b28d

Check it out here: https://blogs.msdn.com/b/edhintz/archive/2011/01/18/tfs-guide-for-subversion-users.aspx

Last week, Aaron Bjork posted a much better solution for teams with custom process templates.  Check it out if you need a solution for changing work item state when checking in changes but aren’t using the Resolve state.

https://blogs.msdn.com/b/aaronbjork/archive/2010/12/17/marking-tasks-and-bugs-as-done-during-a-check-in.aspx

To make “Associate” the default action (instead of “Resolve”), set the registry key “HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0\TeamFoundation\SourceControl\Behavior\ResolveAsDefaultCheckinAction” to “False”. 

FWIW, in our next release, we’re fixing this experience so that you won’t need to hack the registry to change the behavior.

You can download the tools here: https://visualstudiogallery.msdn.microsoft.com/en-us/5a8d1703-7987-4081-ba2f-9d0b68b0ed3e

Any questions or feedback on the tools can be given through the TFS Integration forum on MSDN.

5/11 - It seems that the last update of the TFS Integration Tools broke my link above.  The Migration and Integration Solutions page should always contain a working link for the TFS Integration Tools moving forward.

When creating mappings for your workspace, keep the following points in mind:

1. Map high enough (that is, closest to the root, $/) to ensure that you’re not updating your mappings every time a new piece of code is added. 
2. Map low enough to prevent downloading things you don’t need to do your development work or to build your code.
3. Keep your mappings simple – the fewer the better.  Only add complexity if it is necessary.

Balancing each of these things is something that is really only possible when the details of the specific projects are known.  There are some general best practices that may also be useful when creating a workspace:

1. Mapping at the Team Project level is a common approach, and may be a good idea if you only work in one Team Project.  Team Projects and workspaces are both tools to provide isolation, so a 1:1 mapping makes sense.
2. One branch per workspace is a good practice to isolate changes that don’t logically go together.  For example, you probably don’t want to see pending changes from your production branch shown along side your changes for your development branch.
3. Using multiple workspaces is a great way to work effectively if you work on multiple projects in parallel and task switch often.

Hopefully that will provide some help to users that are new to TFS until we have better guidance on MSDN. 

In the UI, history of folders is recursive - always.  This is because most of the time, users care about the history of the contents of the folder.  Files on the other hand don’t have the concept of recursive history - you always see the history for the file itself.  Now, from the command line, there is an option to show recursive history (/r) and if you run “tf history” on a folder without the recursive option, you'll see the changes to the folder itself.  This would include changes such as a rename for the folder itself.

As for getting this in the UI in VS - we've heard multiple requests for this, and we're tracking it as a possible feature for the next release.

Because this hotfix applies to the upgrade of version control content, it must be applied after TFS 2010 setup is complete, but before configuration is started.  At the end of the setup experience, the Success screen is shown (see below), indicating the completion of the installation.  Normally, users would continue on to the configuration experience, but in this case, the process needs to be cancelled by un-checking the “Launch Team Foundation Server Configuration Tool” box, which will enable the Cancel button.

After exiting setup, the hotfix executable can be run to update the upgrade steps. Once the hotfix is installed, the TFS Configuration Wizard will need to be re-launched from the Start Menu to complete the upgrade process.  As a reference, I’ve shown the welcome screen for the Configuration Wizard.  If you get to this screen and haven’t applied the hotfix yet, cancel out of the wizard and apply the hotfix.

• Labels that were created before the upgrade are entirely empty.  Labels could be also have incorrect contents.
• The merge wizard in Visual Studio does not display all valid merge targets for a given source path/branch.
• During merging, merge candidates are shown for changes that were already merged prior to the upgrade.

If you’ve experienced any of these symptoms following an upgrade to TFS 2010, please check out the KB article: https://support.microsoft.com/kb/2193796

We’re also in the process of releasing a hotfix for the issue for any customers that have not yet upgraded to 2010 that will fix the issue.  When the hotfix is available, the KB will be updated, and I’ll post back here as well.

Update, 6/17 – The hotfix is now available on Code Gallery: https://code.msdn.microsoft.com/KB2135068