Why doesn't check out also get latest?
Dave just asked me why Team System doesn't provide an option to get latest along with every checkout. As I mentioned in an earlier post, the problem is partly one of terminology-- "check out" doesn't really mean Check Out in Team System source control. It means "make editable".
There might be some expectations set here by Visual SourceSafe, too, which has a very different lock-modify-unlock model of checkout. Yet another unfortunate way that Visual SourceSafe poisons the mind of developers. ;)
Terminology aside, it's questionable whether you would really want to get the latest version of the files at the time of your edit, as Doug Neumann points out:
It turns out that [not getting latest] is by design, so let me explain the reasoning behind it. When you perform a get operation to populate your workspace with a set of files, you are setting yourself up with a consistent snapshot from source control. Typically, the configuration of source on your system represents a point in time snapshot of files from the repository that are known to work together, and therefore is buildable and testable.
As a developer working in a workspace, you are isolated from the changes being made by other developers. You control when you want to accept changes from other developers by performing a get operation as appropriate. Ideally when you do this, you'll update the entire configuration of source, and not just one or two files. Why? Because changes in one file typically depend on corresponding changes to other files, and you need to ensure that you've still got a consistent snapshot of source that is buildable and testable.
This is why the checkout operation doesn't perform a get latest on the files being checked out. Updating that one file being checked out would violate the consistent snapshot philosophy and could result in a configuration of source that isn't buildable and testable. As an alternative, Team Foundation forces users to perform the get latest operation at some point before they checkin their changes. That's why if you attempt to checkin your changes, and you don't have the latest copy, you'll be prompted with the resolve conflicts dialog.
To make things even more confusing, the meaning of the term "checkout" differs quite a bit across source control systems. Martin Woodward has a nice post (with fancy illustrations!) explaining the differences:
Internally in Teamprise, we have been having a lot of discussions about check-in and check-out in Team System and how to explain this concept to our end users. The problem is that the terms are overloaded depending on the source control system that you come from. In Visual Source Safe (VSS) or PVCS, check-out means “give me the latest version of the file and lock it so that no-one else can edit it”. In CVS and subversion, checkout means “get the latest version”. If you are using the source control features in Team System then checkout means “Tell the server I want to edit this file and mark that file as writeable in my file system”, at the same time that you check-out the file you also get an option to lock the file using one of three lock types (none, check-out and check-in).
In general, it's a good idea to periodically do a Get Latest operation with Team System. But you control when the integration occurs, not the source control system.