Adam Singer, the newest addition to my blogroll, recently blogged about the Lock Command in Visual Studio Team Foundation. Even if you don't have a CTP or beta build of Visual Studio 2005 Team System, I recommend his post.

Locking in VSTS points to one of the most obvious differences between the Team Foundation source control system and Visual SourceSafe: checkout models. By default, when you check out a file in VSS, nobody else can check out the file until you check it back in. We call this "exclusive checkout mode". IMO, the first thing you should do when you create a new VSS database is to change this default to Allow Shared Checkouts. For more info about how to and why you might want to do so, see Copy-Modify-Merge for VSS.

Alternatively, Team Foundation enables multiple users to check out the same source-controlled item concurrently, by default. When you use tf.exe (the Team Foundation command line executable) to check out an item to which another user has made a pending change in another workspace, information about the nature of their change is printed on the command line. In the following example, we check out a file called Math.cs and Team Foundation then notifies us that two other users are working on the file (Alberto and Juan), tells us exactly what type of pending change each user has in their local workspace (Edit and Rename) and informs us that our local version of the file, the current workspace version, is not based on the latest repository version.

D:\dev\projects\calc\src>tf edit math.cs


   opened for edit in Workspace21;SUDAMERICA\albertori
   opened for rename in WS24;EUROPA\HansTeu
   newer version exists in the repository

Slightly off subject: what would you do first in this situation? Sync to the tip version in the repository? Email Alberto? Call Hans? I'd probably run tf undo math.cs to undo my checkout, run tf get * /noprompt to sync my workspace to the latest repository version (the tip), and then go home early to avoid the fireworks.

The scenario presented in this example is an extreme rarity. Nevertheless, if you were to see that two other users were editing a file you just checked out, how likely would you be to start writing code? Not very.

In most collaborative development environments, the probability that you will make a change in your workspace that conflicts with a pending change in another workspace or vice versa, is unlikely. A great majority of workspace conflicts that do occur are resolved automatically by Team Foundation. For conflicts that cannot be resolved automatically, such as will be the case when Alberto tries to check in his edits after Hans has checked in his rename, you can use the Resolve command to safely decide which change, yours or theirs, you want to keep. If you are concerned that another user might make changes in their workspace that conflict with your pending changes, you can use the Status command to monitor all other workspaces that map to the repository for newly applied changes. If you're downright neurotic, you can use the Lock command as outlined in Adam's post to prevent other users from checking out or checking in changes until you have checked in and unlocked your own.

Best Practices for Locking in Team Foundation:

  • Use the Lock command with discretion
  • Be a cool cat. Use checkout locks, not checkin locks.
  • Notify your teammates when you lock a file and tell them why
  • Notify your teammates when you remove a lock so that they can revert your changes ;-).

For more information about the not insignificant differences between how checkout works in Team Foundation and Visual SourceSafe, see Team Foundation vs. SourceSafe | Checking Out.


Hyperbolic Disclaimer   Microsoft Visual Studio 2005 Team Foundation is an orange tree and Microsoft Visual SourceSafe is an apple. They're both sweet but they don't compare. SourceSafe is a standalone source control system for individual developers and small teams. Team Foundation is an integrated work item tracking and source control system for professional development teams of any size. For more information, see The [new] Future of Visual SourceSafe and Microsoft's New Source Code Control Application.