Condividi tramite

Team Foundation vs. SourceSafe | Locking vs Exclusive Checkouts

  • Articolo

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

ExplorerScc.cs

$/MathPortfolioProject/dev/calc/src/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.

Comments

  • Anonymous
    October 07, 2004
    The comment has been removed
  • Anonymous
    October 07, 2004
    I agree about the proj files, but I think an even bigger pain are forms. Especialy main application forms that have a lot of contention on them. The min. you open a form in a designer and change something, the entire file changes.

    To me what is important is that the system doesn't always try to auto merge, but instead just helps you merge. A good diff/merge tool is a must in this situation. Does team system have a better diff tool than VSS?
  • Anonymous
    October 07, 2004
    >>"To me what is important is that the system doesn't always try to auto merge, but instead just helps you merge."<<

    VERY interesting. I was sitting in a cognitive ui walkthrough (internal usability study of sorts) yesterday and this very topic of conversation came up. Thanks for your perspective, Jeff!

    How do the rest of you feel. Do "silent merges" scare you? Or do you want to be able to switch into "verbose merge" mode?
  • Anonymous
    October 07, 2004
    Silent merges scare me a lot more than the manual effort to merge a file, and I would prefer the manual method, for not only does it accomplish the task, but also educates me on what changed. More often than not, I do have a vested interest in knowing what changed in a file who's source code I can and am actively editing, and that knowledge may affect what I do with my checkin, or after my checkin.
  • Anonymous
    October 08, 2004
    >an even bigger pain are forms.

    We're doing ASP.Net stuff, so I hadn't run into that, but even the ASP designer has a terrible tendency to munge files simply by opening them (though it's my understanding that that's FINALLY fixed).

    >Do "silent merges" scare you?

    I sure don't trust 'em. But then I'm one of those people that always runs a diff immediately before checking in to make sure nothing unintended gets in. I don't mind if the system attempts to merge, as long as I get to view the results first and then say OK.

  • Anonymous
    October 19, 2004
    I don't trust silent merges, either. It's fine to have them as an option, but not the default. No real developer would or should commit without seeing what changes are about to be made.
  • Anonymous
    February 16, 2006

    VSS vs. Team Foundation Version Control | Checkout Behavior
    Team Foundation vs. SourceSafe | Cloaking...