VSS vs. Team Foundation Version Control | Checkout Behavior

"Unexpected Get" was the subject of a very interesting email thread that passed through my Outlook Inbox today. I mentioned the issue it raises in a previous post: Team Foundation vs. SourceSafe | Checking Out. Basically, VSS and Team Foundation perform check out operations in two very different ways.
   Note   For an explanation of acronyms and codenames used in this thread, please refer to the end of the post.

---------------------------------------
Subject: Unexpected Get

[VSS User] I have a question about unexpectedly getting a file when checking out. For example… I checkout a file and while it’s being checked out a new version is downloaded from the SCC provider. Can this ever happen?

[VSS Team Member] Actually this is the default behavior of all commands in VSS 6.0x. Get of latest database version is performed on operations like Checkout, UndoCheckout, and Checkin.
This default behavior will change in VSS 2005. By default, VSS 8 will checkout the local version (whenever possible to determine what the local version is), similar to SourceDepot’s behavior.
Note that using COLV increases your chances of having to merge the files during checkin.
Users who like the old behavior will be able to change this via Tools/Options.

[VSS User] Thanks!
Is there already an option for this in Whidbey?

[VSS Team Member] VSS 2005 will ship in the Whidbey release of VS2005, so yes.
If you work on a newly created database you should have COLV by default.
If you work on an older database, the VSS database administrator needs to uncheck in SsAdmin in Tools/Options/General the “Only allow checkouts of the latest version” checkbox and the users may need to express their preferences in SsExp (in Tools/Options/General check “Always check out the working folder version of the files”)

[VSS User] I actually needed to figure out how to turn OFF this option. I’m not sure how new my database is but I turned off the “Always check out the working folder version of the files” in Whidbey using “Tools/Options/Source Control/Plug-in Settings/Advanced” on the general tab which is another way to get there. This got the ‘unexpected get’ behavior working for my tests.
Thanks again.

[VSS Team Member] This option has a negated logic of turning it on and off J
If you uncheck “Always check out the working folder version of the files”, you’ll be checking out the latest database version (same as VSS6 did), which will cause the ‘unexpected get’ behavior you’ve noticed.
To get rid of the ‘unexpected get’, you need to check “Always check out the working folder version of the files”, so you’ll be checking out the local version (COLV), same as SourceDepot and VSS8 does by default.
Note that COLV feature will not work correctly if you delete vssver2.scc files from local disk, or if you checkout in the same local folder files from different folders in database, etc.

(Acronym/Codename==Meaning):
COLV==Check Out Local Version
GLV::Get Latest Version
SCC==Source Code Control
SourceDepot==Microsoft's internal SCC tool
SSAdmin==SourceSafe Administrator user interface
SSExp==SourceSafe Explorer user interface
VSS2005||VSS8==Visual SourceSafe 2005
VS2005==Visual Studio 2005
Whidbey==code name for Visual Studio 2005 (VS2005), with which the next version of SourceSafe will ship.

So I guess VSS and Team Foundation aren't so different after all... ;-)

++++++++++++++++++++++++++++++
Big Smiling 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 version 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. So do you approve of the title of this post, Buck?