Some Benefits of “Checkout” in TFS Version Control

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:

• How to: View and Manage All Pending Changes in Your Workspace (MSDN)
• How to: View Pending Changes in Other Workspaces (MSDN)

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.

Comments

• Anonymous
  August 18, 2009
  One of the reason I prefer the checkout status is a reflection of the way I work.  I live in the Pending Changes window during my active work.  Before checking in and often throughout active development, I will run through and look at what I've modified to see if I've gone to far or unintentially modified something.  Not having to do a full source tree Compare is nice.

• Anonymous
  August 18, 2009
  The use of a checkout paradigm doesn't really bother me much, except for one little thing: I really hate seeing unmodified files pollute the change history simply because they were checked out.  If there were an option to automatically undo rather than commit a unmodified checked out file during a check-in, I would find the checkout approach quite a bit more palatable. BTW, Subversion somehow manages to handle #4 just fine, so it's not really much of an argument in favour of checkouts...

• Anonymous
  August 18, 2009
  @Nicole - I hear your point, but TFS handles this.  When you check in, TFS detects whether the files have actually changed or not.  If they haven't, then the checkout is automatically "undone" and no unchanged files pollute the change history. Thanks for your additional point on #4. I'm not too familiar with how SVN handles this, but one possible advantage here is that since TFS knows what files you have checked out, only those files are sent down from the server when you issue an undo.  If you have a large repository, then this could be a big savings in file transfer and server time.

• Anonymous
  August 18, 2009
  Personally, I like the checkout model even when I'm only working on a personal project; I use more than one machine, and frequently have more than one workspace on that machine anyway (reflecting different features that I'm working on that I want to remain orthogonal until I commit one or the other). Seeing which files "the other me" has checked out is often valuable.

• Anonymous
  August 18, 2009
  @Matthew Interesting approach.  In this case, essentially you're thinking of workspaces as personal branches (that aren't really branches).  Thanks for the perspective!

• Anonymous
  August 19, 2009
  I did not know that the option to get latest on checkout was there!  Very cool! I definitely agree with Ryan, "Pending Changes" keeps me focused and on-task and also allows me to properly comment and/or tie checkins to a specific TFS item.  We use pending changes quite a bit to determine areas for special testing emphasis.

• Anonymous
  August 19, 2009
  Nice to hear from you @Carl!  Thanks for the comment!

• Anonymous
  August 20, 2009
  Hi, I'd like to add two points: #1 Subversion has a copy of the checkout revision of each file in the .svn folder. The downside of this approach is that it doubles the required space on the HDD (each file is held twice). On the other hand it's pretty cool because it means that I can even undo changes locally - without contacting the server. This is especially helpful in offline scenarios and is much faster than a TFS undo. #2 Although I like the checkout model more I think the usability of the Pending Changes window is really bad. When double-clicking a file in Pending Changes I'd like to see the differences between the base version and the version I'm going to commit, because what I need this window for is reviewing changes and finally committing them. The current implementation does not really reflect this because the fast and easy double click opens a file in source editor (usually unwanted result) whereas for the standard use case (view diff) I need to take the longer route of right click -> Compare -> With Workspace version -- and I need to click that sequence for every single file I want to check. Could you address this in a future release, please?

• Anonymous
  August 21, 2009
  The disconnected mode in TFS does need more work as far as being able to see the pending changes.  The only way I could see to do this, however, is to duplicate the files on disk to have a baseline to compare pending changes to. The current default double-click action of the pending check-ins works great for me.  Many time when working a feature, I need to perform multiple changes to files.  Reopening fits me typical needs.  Perhaps to address, Ooh's request, the default action could be configurable. Also, I love the aspect of TFS as source control being sln/proj based rather than file-based.  If a file exists but is NOT included in the solution, it isn't monitored.  Much easier to maintain than some exclusion list that may differ among team members. All in all, a great product that once you stop thinking "its just SCM" you really see how powerful it can be.

• Anonymous
  August 26, 2009
  There is a toolbar button in Pending Changes that offers 1-click "compare vs workspace version" and 2-click access to the other diff types. Still, I agree there's a strong argument for changing the doubleclick behavior. The annoyance is even MORE apparent in the Shelveset and Checkin modal dialogs (which share a common codebase with Pending Changes).  I'd venture to say that launching Notepad out of those modals is only the desired behavior 1/100 times. If fixing that obviously wrong doubleclick action to Diff also changes PC, it's worth it, even though I'm very used to the latter and don't find it lacking.  

• Anonymous
  October 26, 2009
  Hi, 1.after check in the files, files are not getting reflected in tfs for the new few minutes. when i track the history, i got to know the file is checked in after few minutes. for example file A has been checked at 1:30 manually but in the history it is showing at 1:33. I am getting the gap of 3 mins. What should i do if the files to be reflected in tfs for the next moment. I am using TFS2008. Please let me know.