If you’re like me and need to do code-reviews of other people’s stuff or maybe you just want to see everything that’s changed during a certain period of a project, then here’s a nice PowerShell tip for you.
First, make sure you’ve downloaded the latest version of the Team Foundation Powertools. Starting with the October ‘08 release, the tools now include a PowerShell snap-in that add several commands which enable rich interaction with your Team Foundation Server. Of particular interest to us for this exercise though is the Get-TfsItemHistory command.
Now, let’s assume a scenario where we have a Team Project named $/Foo and we’ve been working on some patches in a v1.1 branch within that project. Now it’s time to review the work we’ve done in the current iteration which started on March 1st ‘09 and ended on March 31st ‘09. Here’s how we might start gathering those changes:
Get-TfsItemHistory “$/Foo/v1.1” -Version “D3/1/09~D3/31/09” -Recurse
Now, what this is gonna do is bring us back all the changesets that are related to any file underneath the v1.1 branch. While listing out the changesets is nice, it’s not going to tell exactly which source files I need to review. So the next thing we need to do is make sure we bring back all the changes in the changesets by adding the -IncludeItems parameter to the Get-TfsItemHistory call. We’ll also want to do is flatten out the list because, again, we’re interested in the indvidual changes, not the changesets themselves. So we use Select-Object’s -Expand parameter to flatten out the list:
Get-TfsItemHistory “$/Foo/v1.1” -Version “D3/1/09~D3/31/09” -Recurse -IncludeItems | Select-Object -Expand “Changes”
Great, so now we have a list of all the changes that were made to each file in this release, but this is still a little noisy. For starters, change types such as deletes, branches and merges are shown here. Well, if the file was deleted there’s not much to look at now, so… I don’t want those in my list. Also if a file was simply branched into the project from someplace else we don’t really care because wherever it came from already underwent a review. Merges are also questionable as, hopefully, the merged was reviewed for any conflicts at the time the merge occurred. Plus if there was a conflict that means they must have changed the file which will show up as a standalone edit anyway which means it will still end up on our list. So, how do we filter that noise out? Like so:
Get-TfsItemHistory “$/Foo/v1.1” -Version “D3/1/09~D3/31/09” -Recurse -IncludeItems | Select-Object -Expand “Changes” | Where-Object { ($_.ChangeType -band ([Microsoft.TeamFoundation.VersionControl.Client.ChangeType]::Delete -bor [Microsoft.TeamFoundation.VersionControl.Client.ChangeType]::Merge -bor [Microsoft.TeamFoundation.VersionControl.Client.ChangeType]::Branch)) -eq 0 }
Alright, almost there! Now the only problem is that if the same file is changed multiple times it’s going to be listed multilple times and really we just want the distinct names. This is a little tricky because the Change object contains the Item as a Note property, luckily there’s a Select-TfsItem command to help read what we’re interested in out. After that we just do a little grouping and sorting and we have a list we can work with:
Get-TfsItemHistory “$/Foo/v1.1” -Version “D3/1/09~D3/31/09” -Recurse -IncludeItems | Select-Object -Expand “Changes” | Where-Object { ($_.ChangeType -band ([Microsoft.TeamFoundation.VersionControl.Client.ChangeType]::Delete -bor [Microsoft.TeamFoundation.VersionControl.Client.ChangeType]::Merge -bor [Microsoft.TeamFoundation.VersionControl.Client.ChangeType]::Branch)) -eq 0 } | Select-TfsItem | Group-Object Path | Select-Object Name | Sort-Object
Finally, in true PowerShell fashion, this will write the paths out to the host (console or ISE), but naturally you could also Export-*, Out-*, etc as well.
