Team Foundation server maintenance notes

The team Foundation server of the project team is ready for operation, but some problems have also been found during the past few days. It is no wonder that in Microsoft products, I feel that TFs is the most integrated with many products and services, therefore, the problem is also a strange competition from other heroes, and TFs problems are particularly difficult to solve, so from this Maintenance note, I am going to put my problems in TFs maintenance, we hope that you can avoid detours and difficulties in using TFs.
We use sourcecontrol in TFs when using TFs. I don't need to talk about the advantages of sourcecontrol, but sourcecontrol has a fatal disadvantage, this is also a problem caused by sourcecontrol in work zone-based mode. First, sourcecontrol source code management creates a work zone on each client machine and maps the work zone to the source code folder on the server, during Normal check-in and check-out, our source code will be operated in the work zone of the server to the client. This is correct, however, when using TFS, we usually use concurrent check-in and check-out by multiple people, while TFs supports check-in locks and check-out locks during design, by default, the project team members do not apply the check-out lock when checking out the project (the limit is relatively large, and it is recommended that the project team members use the lock with caution) and check in the lock (the limit is smaller than the check-out lock ), however, once a project team member checks out the source code project from the sourcecontrol of TFS, and adds the check-out lock or sign-in lock, it doesn't matter, as long as the members of the project team follow the rules to check the project to sourcecontrol, the check-out lock will be automatically removed. The key issue is that if the members of the project team are on vacation, or the members of this project team have left. There are too many reasons for this. For various reasons, there may be several files in the project of this project team that have applied the check-out (inbound) Lock, at this time, if the next member of the project team wants to modify the locked file, or the TFS administrator wants to delete the project in sourcecontrol, the problem arises, because we cannot perform this operation through team explorer, when we delete such a project through team explorer, Team Explorer will prompt that there is a check-out (inbound) Lock, then, let us know which user is and which workspace is locked. The definition of a workspace should be like this, for example, workspacesample; domain/wangxiaolong: 6, which is a complete definition of a workspace, in this case, do not rush to use the following command:
Cd c:/program files/Microsoft Visual Studio 8/common7/ide
Then execute

TF Undo/workspace: workspacesample; Region/User name: username No. $/path/file name
Workspacesample; the parameter field/user name in the region is a complete workspace, so you do not need to figure it easily and miss this most important parameter,
Then you can refresh your team explorer to see if the locked file is missing. You can perform more operations.