Some Benefits of “Checkout” in TFS Version Control

  • Article

One of the more common points of confusion around TFS source control is the checkout model.  This typically comes from users who are more familiar with the checkout-less model (e.g. Subversion).  I acknowledge the TFS approach is a different model, and there are certain advantages and disadvantages to each approach.

For single users or very small development teams where you don’t have 2 or more people working on the same files very often, I understand the feedback that the checkout model in TFS feels heavyweight at first glance.  We’re listening to your feedback and we’re looking at options to improve this experience in future releases.  In the meantime, I hope this list helps explain some of the advantages in the TFS approach (as I see them).

1. You can see what other people are working on.   When you view source files in the Source Control Explorer under Visual Studio or use the “tf status” command line command, you can see who else has files checked out and what types of pending changes they have.  Most often, you’ll see “edit” commands, but occasionally you’ll see someone with a pending delete or rename that could cause headaches for you when you try to merge your changes to the file later (if they commit first, for example).  Knowing this in advance helps you know when you need to either commit your changes first or to start a conversation with the other person modifying the files.  Also remember that in a team environment, people other than developers might be interested in knowing what changes are coming up.  Testers, for example, might want to get prepared for upcoming changes by watching who is currently working on files for features they test.  Note that you can only see what types of pending changes other people have on files and folders, but you cannot see the actual changes until they are committed to the repository.

2. Prevent two people from trying to edit the same non-mergable file types.   Certain file types such as images, audio files, SQL Express databases, etc. cannot be merged.  Many of these file types are configured for “exclusive checkout” out of the box in TFS.  This means only one person can check them out for editing at once.  This prevents the ugly situation where 2 or more people have modified the file and then try to commit their changes back to the repository.  For these non-mergable file types, the only 2 options are to check in and replace the latest version with your own or to discard your changes.  A TFS administrator can add or remove file types from the “exclusive checkout” list.

3. Allows an administrator to limit who is allowed to make changes to a file before they make the changes.   Rather than finding out when you try to merge your changes back to the repository that you don’t have permissions to edit a file, an administrator can limit who has the “checkout” permission.  If you try to check out a file for editing and don’t have this permission, then you’ll find out before you spend any time actually modifying the file.

4. You can easily undo local changes.   Since the server knows what you’re working on and what version you started from, you can easily discard some or all of your pending changes and revert back to the state you started from.  Use the Undo Pending Changes context-menu command in the Solution Explorer or Pending Changes Window, or “tf undo” from the command line.  Issuing an “undo” will revert your local files back to the state they started from, even if other people have committed changes to the server since you initially checked out your files for editing.  If you want to catch up to the latest versions on the server, just do a “Get Latest”. 

5. (TFS2008 forward) You can “get latest on checkout”.   TFS 2008 and later versions have a feature (off by default) that will automatically get the latest version of a file when you check it out for editing.  This is handy because you always know you’ll be working on the latest committed version when you start making changes.  Of course, other people might come along and commit changes before you commit yours, but in general it should help to reduce the number of merges you need to do by making sure you’re not starting off from an older version of a file. This is especially helpful for users migrating from Visual Source Safe which had a “Get Latest on Checkout” behavior.  Note that this could lead to a state where your project doesn’t build after you check out files (because you have the latest version of some and older versions of others), and that’s why it’s off by default.

For reference, here are some related articles and posts that might be helpful to you:

As always, we love to get feedback on what does and doesn’t fit your needs.  Feel free to post your thoughts on the checkout model of TFS here or in our forums.