Team Foundation Server (TFS) is a powerfull system for source countrol, project management and more. Unfortunately, as is the case with most MS products it comes with a clunky UI that is not a lot of fun to work with and is often just marginally usefull. Fortunatly, as is the case with most MS products, there are several ways to “roll your own” solution. In the days before powershell, that usually involved a Visual Studio macro or a console aplication, but now that .NET has come to CLI, we have more options.
One of the most common questions in a typical Software Development Life Cycle (SDLC) is “what changed?” There are different flavors of this question, we’re going to try to address two of them:
- What Changed for this folder?
- What Changed for this Project?
The answer to both of these question would have to consist of the following:
- workItem ID
- changeset ID
- change Type
- File Name
- File Path
In order to answer these questions, let’s look at how TFS organizes the relevant information. Any file/folder being tracked by TFS will belong to the following heirarchy:
- Item Object – a file or folder that we actually want to know about
- Change Object– describes what happened with an Item. All possible source code actions recognized by TFS belong to the Change Type Enum. These are the changes that we want to know about.
- changeset– a collection of Change objects, it is a logical container for everything related to a single check-in operation. If you care about the checkin notes, date, etc. this is a very useful object for you. For the rest of us its utility is mostly in its links to other object. such and Change and Work Item.
This Magnicent Trio will allow us to locate any changes to any file under TFS source control. But we need one more object to get the answers we’re looking for:
Work item Object– A single unit of work which needs to be completed. It can be of several different types, such as a Bug, a Task, a Quality of Service Assessment, a Scenario, and so forth. Costum types can be defined as required. It is in a many to many relationship to the Changeset Object.
There are many ways to skin the cat. Sometimes a mixed CLI/UI solution is good enough, such as when we know the changeset # and just want to look at the changes it contains. For this, we can use tf changeset, (more information on tfs command line tools can be found here)
But if you’re reading this you’re probably looking for something more sophisticated. If you don’t already have it, get TFS Power Tools (in case you need it, here is the 2010 version) and load the powershell cmdlet.
- If you want changes associated with a given path use Get-TfsItemHistory, a cmdlet that can use either a local or a TFS server path. Ability to use the TFS server path is very important as it eliminates the need to download the latest changes to the local workspace.
- If, on the othere hand you want to find changes to a particular Work Item, you will need to acess it via TFS API.
In the following posts I will explain how to get relevant Change objects from these two entry points.
Stay tuned.
