Get current changeset id on workspace for TFS
How do I figure out what changeset I currently have in my local workspace?
Sure, I can pick one file and view its history. However, if that file was not recently updated, its changeset is probably older than the more recently updated files in the same solution.
One possible mistake that we may make is that we view the history on the solution file, however the solution file rarely changes unless you're adding a new project / making solution-level changes.
In the end to figure out the changeset I need to remember what were the latest files changed and view their history.
Is there a better way to do this?
Your answer is on a MSDN blog by Buck Hodges: How to determine the latest changeset in your workspace
from the root (top) of your workspace, in cmd perform:
tf history . /r /noprompt /stopafter:1 /version:W
Run a Visual Studio CMD (in my case, for VS2015 is called: "Developer Command Promp for VS2015") and then get into your project folder and execute the following command:
tf history . /r /noprompt /stopafter:1 /version:W
The common answer to use tf.exe history . /r
directly does work, but it can be horribly slow. In our case it takes 10-15 seconds.
I now use a two stage check, first checking the revision of some arbitrary files (I'm using the files in the root folder).
With powershell:
$tfexepath = "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer\tf.exe"
$localpath = "C:\some\tfs\directory"
$result = & $tfexepath history $localpath /noprompt /stopafter:1 /version:W
"$result" -match "\d+" | out-null
$id = $matches[0]
Then search from the root using the /r flag, but limit the search to start from the revision found above:
$result2 = & $tfexepath history $localpath /r /noprompt /stopafter:1 /version:$id~W
"$result2" -match "\d+" | out-null
$id2 = $matches[0]
#result:
Write-Host $id2
For our code base, this brings down the total time from 10-15 to 1.4-1.5 seconds.
As far as I understand there are no drawbacks or limitations, but I suppose it could be slower in a tiny repository. - I'd be glad to know.