TFS “GetLatest” and “GetSpecific” version of code – the definitive guide

At my office we we discussing the differences between these two ways of getting source code from TFS are, and I wanted to find out once and for all. I have found some people generally use Get Specific because Get Latest “doesn’t work” / is buggy / is unreliable / doesn’t actually get latest code (?) or something similar.

  • What are the real differences between them?
  • When should we use one and not the other?
  • How do Workspaces fit in with these two features?


OK. To start with, I went through Workspaces and how they work – and, importantly, how do they make TFS by default act differently from SourceSafe (VSS)? This is how I understand it: –

Workspaces are a local cache of the code in TFS. When you pull code out of TFS – whether it’s by GetLatest or GetSpecific – the code is stored locally in some folder that you never know the name of (or care about, really). The files in this workspace can be thought of offline-version of TFS against which all your changesets are managed.

Checking out a file

When you edit a file for the first time after getting code, the TFS plug-in does the following: –

  1. If you are using single check-outs, the plug-in checks with TFS to see if the file is locked. If multiple check-outs are permitted, this is ignored.
  2. If the file is unlocked, the plug-in removes the read-only lock on your local file and marks the file as checked out in TFS.
  3. Assuming (2) was successful, if you are using single check-outs, it also places a lock on the file to prevent anyone else checking it out at the same time.

At no point in this process does TFS check whether the version of code in your workspace is the same as what is centrally stored in TFS.

Checking in a file

Imagine the following scenario (assume that we are using single checkouts for simplicity): –

  1. On Monday Jim does a Get Latest (or Get Specific) of all files in a TFS project. This code is copied onto his local machine’s workspace, and also to wherever he has mapped the workspace to e.g. C:\Dev\MySolution etc.
  2. On Tuesday Sally start to work on File A and checks it out exclusively. At this point, TFS knows that she has a check-out on the file, but that’s all. It does not know what the changes she is making to that file are.
  3. On Wednesday she checks in her changes of File A. TFS now has the latest version of code. Jim’s workspace version of the file is unchanged.
  4. On Thursday Jim decides to modify File A. The plug-in checks out the file exclusively to him and places a lock on the file in TFS as already described. The version of the file he modifies is the original version he got on Monday. He does NOT get the version which was checked into TFS yesterday by Sally.
  5. On Friday Jim is finished with his work and checks it in. The TFS plug-in pops up with a message asking him to merge his changes in with TFS’s version of the file. This is to resolve the changes he has made and the ones that Sally made earlier in the week.

This shows that you can get the merge dialog even in a single check-out environment, not just with multiple check-outs.

The old VSS way that this process would have worked would be on editing the file ((4) above) that the plug-in automatically pulls down the latest version of File A. The reason why TFS does not do this is to prevent you accidentally breaking your local build i.e. you get the latest version of File A which references File B which was checked in at the same time by myself on Wednesday. You don’t have File B, so your build will break, forcing you to do a full Get Latest of code.

You can do it get the TFS plug-in for VS to behave in this way: –

  1. Open up Team Explorer.
  2. Go to the root node of your project.
  3. Right click and select Team Project Settings –> Source Control… (you will need Project Admin rights to get this option)
  4. Select “Enable get latest on check-out”.

That’s it – you’re back to the original VSS behaviour.

Get Latest vs Get Specific version

I’ve searched everywhere for a definitive answer to this one. I’ve been using Get Latest since we started using TFS and don’t get any problems with it, ever! What I have read is this: –

  • Get Latest will synchronise your local workspace (and the mapped development folder) with all the files checked into TFS. This means it will: –
    • Update files already in your workspace that differ from TFS (bringing up the Merge dialog if necessary)
    • Add any new files into your workspace
    • Remove any deleted files from your workspace
  • Get Specific (provided that tick a few of the boxes in the dialog) will get EVERY file from TFS under the node you’ve requested, even if they match the copy of the file in your workspace exactly.

When is Get Specific “better” than Get Latest?

Under what circumstances would Get Latest not be enough for you? I can’t think of any for day-to-day development. I’ve found a few blogs on this issue – the overriding situations where Get Latest will not get your the same set of files on your machine is if you have :-

  • Removed files outside of Visual Studio, in which case the TFS plug-in will not know that you have removed the file and will not get it from TFS when you do a Get Latest because it still exists in your workspace. The solution is to either delete it through Solution Explorer in VS or through Team Explorer. Conversely, if you delete a file in e.g. Windows Explorer, when you check-in your changes, I don’t believe that TFS will know that the file has been deleted (for the same reason), so won’t delete it from TFS. If someone can confirm this that would be nice 🙂
  • Removed the lock on a file manually i.e. right click to get properties and remove the Read-Only flag. In this case, when you Get Latest on the file, it will not do any change tracking because again the workspace does not know that you’ve editing the file, because you never had to remove the lock in the first place.

When is Get Latest “better” than Get Specific

There’s nothing “better” in terms of the accuracy of files that you will get using Get Latest. However: –

  • It’s much quicker, as it only pulls down files that are different between your workspace and TFS. In a slow network environment this might be very important!
  • You don’t get VS going bananas about reloading projects.

Designer-generated files

There is one unique scenario where things can go belly-up when resolving your check-ins – designer files e.g. Forms, Entity models, DataSets etc. which have designer.cs / .dbml / xsd / xss files that are generated by Visual Studio when you made changes in a designer surface.

When you check in your e.g. Form, if someone else has made changes to the same form (the visual part, not the “code behind”) in the meantime, VS will fail to resolve the differences automatically and ask you to resolve the changes manually. If you fancy going through a designer generated file, this is of course not a problem 🙂 But I’d sooner undo my checkout on that file, get latest, and make my changes again. In a single-check out environment, the only way to guard against this is to force the “Get Latest on Check Out” feature on developers.

However, in a multiple check out scenario, even using both Get Specific Version and the Get Latest on Check Out feature of Visual Studio will not save you from this situation! As far as I can tell, there is simply no way to prevent it happening. So, if you are using multiple checkouts, be careful when working on designer-generated files – maintain short check-outs on them so that the risk of someone else working on them in the meantime is reduced.

Comments welcome…

See also: –













Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s