An Introduction to Team Foundation Server Version Control from a Visual SourceSafe User’s Perspective
Steven St. Jean has just posted a great document that helps users make the move to Team Foundation Server’s version control. While his goal is to help VSS users, this document will help users moving from a lot of other source control systems as well, such as Star Team. He includes lots of screen shots.
I’d highly recommend this to folks who are trying to learn how to use TFS version control and are coming from a version control system like VSS that lacks pending changes, changesets, workspaces, and other concepts that TFS has. It’s not going to tell you how to administer your team projects or discuss the major branching models, but that’s not the purpose. It’s about getting up to speed on the fundamentals of using TFS version control.
Over the course of the last few months, I have been part of a team working to bring TFS Version Control and MSBuild into my organization. My duties have included everything from process definition to hands-on migration of code from VSS into our TFS repository. An additional (and unwritten) role that I have assumed is to help our developers, QA, and Infrastructure people make the mental transition from the way VSS did things to the way TFS does them. This document was born out of those discussions. I decided to write this up with screenshots from the Version Control Tree Browser project on CodePlex so that it would not have any proprietary corporate information within it. That will allow me to post this for general public consumption without losing my job.
Please feel free to download and use it within your own organizations if you think it is worthwhile. I would appreciate a comment to this posting if you like it, but more importantly, if you don’t. If there’s anything I’ve missed or misrepresented, please let me know and I’ll do my best to fix it. This document will grow with your feedback, so please give all you can.
Download: From VSS to TFS
He includes one of the key issues many new users hit. Here’s an excerpt (the emphasis is mine).
Get Latest Command
As you would expect, the purpose of the Get Latest command is to retrieve the files and versions that represent the “latest” or “tip” of the source control tree. This is just part of its function. As stated earlier, the Get commands actually synchronize your local cache to the state of the files on the server. Any out-of-date (not latest) and new files are downloaded and any deleted files are removed from your local cache. Any renamed files are also updated on your drive. When it is complete, your workstation will have an exact replica of the files on the server as they exist at the moment you asked for them.
Here’s the drawback to this functionality. TFS tracks the files and version you have retrieved in your Workspace. It doesn’t read the file or version data from your local files, but rather from the Workspace’s cached data. If you remove (some or all) files from your workspace through some mechanism other than Visual Studio, TFS will not have any idea that a change has occurred. If you then invoke a Get Latest, TFS will happily tell you that all of your files are up to date and get nothing. This is usually the first “bug” that a user reports.
This feature is a fundamental part of what allows TFS version control to scale, but it catches a lot of folks off guard. If you find yourself in this situation, you can use the Get Specific Version command from the popup menu and choose to get files even if the server thinks you already have them.
The second option is Force get of file versions already in workspace. This is the one that you will use to make TFS behave like VSS. When you’ve deleted files from your local cache, this option will force them to be retrieved from the server even if TFS thinks you already have the most up to date version.
About the only relevant thing I see that’s not covered in the document is branching and merging. I wouldn’t be surprised if he adds that in an update.