BUGBUG: poor title

Depending on how extensively you’ve played with the new TFS powershell cmdlets, you may have noticed one oddity: Get-TfsPendingChange doesn’t always return a PendingChange[] array.

PS C:\workspaces\ws1\MAIN> tfstatus

Version CreationDa ChangeType      ServerItem
                te
------- ---------- ----------      ----------
   7415  2/13/2009 Edit            $/Research Platform (R...rLife.v2 Web.vssscc
   8024  2/13/2009 Edit            $/Research Platform (R...ckerLife.v2 Web.sln

PS C:\workspaces\ws1\MAIN> tfstatus -user rwilliams

Name                Computer            OwnerName           Type
----                --------            ---------           ----
CoatueResearch      CMXP123             COATUECAP\rwilliams Workspace
BuildTypeEditor_... CMXP123             COATUECAP\rwilliams Workspace

The second command is actually returning a PendingSet[] array.  Each PendingSet contains a PendingChange[] array that’s specific to a particular workspace or shelveset, plus some metadata about the workspace or shelveset itself.

What gives?  Actually, the underlying APIs always return PendingSet[].  If Get-TfsPendingChange merely pushed the result of the API call onto the pipeline, as most other TFS cmdlets do, then every time you ran it you’d get something more like this:

PS C:\workspaces\ws1\MAIN> $ws = get-tfsworkspace .
PS C:\workspaces\ws1\MAIN> $ws.QueryPendingSets($null, $ws.Name, $ws.OwnerName, $false)

Name                Computer            OwnerName           Type
----                --------            ---------           ----
ws1                 RICHARD490          COATUECAP\rberg     Workspace

…which is clearly not as useful as the output of the first “tfstatus” example above.  Furthermore, people only use Get-TfsPendingChange (and its tf.exe predecessor) to query across multiple workspaces 5% of the time, if that.  I decided to optimize for the 95% case.  That meant checking to see how many PendingSets were returned from the server, pushing its PendingChange[] array onto the pipeline instead if there was only 1.

Note: the QueryShelvedChanges API we use takes a single shelveset.  Unfortunately that means the cmdlet does not support queries like “show me everyone who has shelved $/project/foo.cs” in a single server call.  (QueryShelvedChanges() does have the necessary overloads; we simply inherited this limitation from tf.exe and didn’t have time to rewrite it).  Thus, whenever you specify the –shelveset parameter to Get-TfsPendingChange, you are assured to get a PendingChange[].

This entry was posted on Saturday, February 14th, 2009 at 12:50 am and is filed under Powershell, Version Control. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.