Exception:

"TF400030: The local data store is currently in use by another operation. Please wait and then try your operation again. If this error persists, restart the application.”

Explanation:

The error occur when using local workspaces in Visual Studio 2012 or later

TFS 2012 and VS 2012 featured with new workspace concept called “local” workspaces.The workspace concept which was available from VS/TFS 2005 - 2010 is called as “server” workspaces 

When a local workspace is created, The required data structures will be moved from the TFS server onto the TFS Client. The data structures are local to local machine instead of being hosted on the TFS server. Moving the data structures to local machine gives VS 2012 the ability to perform a number of source control operations without TFS web service calls. The following operations continue to work when the local machine is disconnected from the TFS server.

• Opening a source-controlled solution
• Checking out a file for edit
• adding a new file or folder for add
• Delete on an existing file or folder
• Rename on an existing file or folder
• Monitor pending changes in the workspace
• Undoing pending changes
• Diffing your copy of a file with the version of the file your change is pended against
• The local workspace will not carry read only bit during get source.
• “Promoting” the candidate adds and/or deletes
• The local workspace will be invisible to VS 2010 and earlier versions
• No enforcement of PendChange permission or checkout locks
• The local workspace can be converted to Server workspace and reverse the same

Local workspaces have scalability limitations due to their use of the local workspace scanner which checks for edited items.If the workspace has more than 50,000 items, There may be performance problems or "TF400030 errors as operations exceed 45 seconds in duration." may occur

Reconciled operation on the server or deadlock between two operations may also trigger the error.

In Local workspace architecture, only a single operation (thread) can use this local data at a time. If two pieces of system want to use the data store simultaneously – perhaps the Solution Explorer and the Source Control Explorer both want to refresh after an Undo operation was performed – then these two components have to take turns to use the local data store. One will wait for the other to finish, and who gets to go first is arbitrary.

The ‘loser’ of the race has to wait before proceeding, but will only wait for about 45 seconds. If he ends up waiting for that full amount of time, but still doesn’t get the chance to use the local data store (because some other component of the system is still using it), then this error will be raised.

Workaround:

• keep the size of the local workspace from growing too large, files and folders less than 50,000 items
• Avoid working with extremely large sets of pending changes (10,000+) for a long time without checking in. This helps to keep ‘reconcile’ costs low
• Install Visual Studio 2012 Update 2 or later to get protected from the deadlock scenarios
• Convert the local workspace to server workspace

Explanation:

A regular get operation will deleted each item in the target workspace folder and re-downloaded the folders and files from the server to target workspace folder.

Solution:

Use remap switch with tf get command

"tf get /remap"

Note: /remap switch does increase the load on server to process your request

Explanation

A lock cannot exist in a shelveset, When you try to lock an item and shelve it, your lock will be removed as part of the shelve operation.

Explanation:

Multiple users mapping their workspaces to same folder on shared drive lead to conflicts in performing checkin, Checkout and "get latest" operations.

Workaround:

You can try users mapping their workspaces to different folder on shared drive.

For example

user 1 -- <Shared Drive>\User 1 Workspaces\

user 2 -- <Shared Drive>\User 2 Workspaces\

user 3 -- <Shared Drive>\User 3 Workspaces\

user 4 -- <Shared Drive>\User 4 Workspaces\

Note: Mapping the workspace to a shared drive lead to bad performance.

Solution:

Solution is to perform a baseless merge using Tf.exe. Following are the steps

1. Perform a Baseless Merge Using Tf.exe

• Open command prompt
• cd "<Work space folder>"
• execute tf merge /recursive /baseless "Parent Folders\Files" "Child Folders\Files"  

          Example:    tf merge /recursive /baseless "$\Project A\Development" "$\Project A\Release\V1.0"

2. Resolve Merge Conflicts

3. Check-In the Merged Changes

You should see the relationship established  between folders\files