If you use Team Foundation Version Control, you have several ways to control whether multiple developers can work on same objects simultaneously. You normally want that, because developers often need to change a common file (a class, a configuration file and so on) and waiting for each other would cause unnecessary delays. But it’s not always the case – maybe you want to lock an individual file before making a sensitive change, some files can’t be easily merged so it’s not wise creating concurrent versions, maybe you’re developing in a shared AX instance and so on.

Before we actually look at locking, it’s important to understand the difference between local and server workspaces, because each of them work with locks differently. A TFS workspace defines which files are downloaded from TFS, tracks edited files and so on. Beginning with TFS 2012, you can choose between local and server workspaces; older versions of TFS support server workspaces only.

Note that you can easily switch between workspace types – simply open workspace properties in Visual Studio, switch to the “advanced” display and set Location to either Local or Server.

If you use a server workspace, a lot of state information is maintained on server, therefore you need a connection to your TFS to perform actions such as checkout or add. Local workspaces can track such actions by themselves, therefore you may be disconnected from TFS (if you have all files you need already in the workspace). If you want to check in changes to version control, you obviously need connection to server regardless of the type of your workspace.

This clearly leads to a difference in when you can apply locks – because local workspaces don’t have to communicate with server on checkout, you can’t expect them to honor locks. Therefore if you need exclusive check-out locks, you have to use server workspaces. Both type of workspaces can use check-in locks, which means that developers can do local changes but they can’t check them in until the lock is released.

Look at Understand lock types if you need more information about lock types and their use.

One way of taking a lock is as a part of check out. Simply choose a lock type in the Check Out dialog:

The picture above is from a server workspace. If I use a local workspace, Check Out lock isn’t available.

You can be offline if you don’t need any lock, but you obviously must have a connection to TFS if you want it to lock the file and prevent others from uploading a new version.

Another option is taking a lock manually.

If you want TFS to take a Check Out lock automatically for certain file types (especially because you can’t merge them), you can configure it in team project collection settings. One option to get to the right form is Team > Team Project Collection Settings > Source Control…

Here you can edit or add file types and configure whether multiple checkouts should be allowed:

And finally, you can disable multiple checkouts for the whole team project (regardless of file type). Open source control settings for an individual team project (Team > Team Project Settings > Source Control…) and uncheck Enable multiple check-out.

People sometimes think that it’s all or nothing (everything locked/unlocked), but you clearly have more options available. And the impact of workspace types can be very confusing for those who don’t understand workspaces.

All pictures are from Visual Studio 2013 connected to Visual Studio Online.