Curious about the source control part of Microsoft Visual Studio 2005 Team Foundation? Tired of looking at feature lists and marketing hype? If so, here’s a word you can chew on for awhile:
When one of the hard-working developers on my team like Buck or James check in their code, their changes usually relate to a single developmental task or a small set of tightly-coupled tasks. I call these ‘task-specific checkins’.
More often than not, a task-specific checkin involves multiple, interdependent revisions to two or more files. Consequently, changes to a single file don’t usually make sense unless they are accompanied by thorough checkin notes, which of course they usually are because the Hatteras SDEs are the best of the best.
By inclination, training, and habit, software developers seem to reject the notion of performing tasks for which an automated alternative exists, or might someday exist. They’re lazy, but smart lazy. If you are a smart lazy developer, you are going to LOVE changesets in Visual Studio Team Foundation.
A changeset is a logical container into which VSTF bundles everything related to a single checkin operation. A changeset consists of:
In a technical sense, a changeset is more than a logical container. A changeset is a version of the repository at a specific date and time. Consequently, you can return your workspace (your personal view of the source control repository) to exactly the way it was when you fixed that pesky crashing bug sometime last month. Oh! And it’s literally this easy to accomplish:
<C:\WS1> vstf Get /version:C349712
This command retrieves a working copy of all uncloaked files and subfolders from the repository to the local workspace with which the WS1 folder is associated as they were at the time when changeset #349712 was created!
When you’re done reflecting on the elegance of your bugfix, you can resync your local workspace to the latest repository version using the following command (assuming that WS1 is the root of the workspace).