1

I have many workspaces that I manage locally while working with our source control system - sometimes though, I will go over 6 months without working on a particular codebase, and just in case I'd like to check which workspace the last changeset came from.

This way I could ensure that no "rogue" files have been worked on locally without being checked in - I know it "shouldn't" happen if I'm checking in on every change, this is just a safety mechanism.

I know I can get the changeset ID from TFS 2017 by looking at the repository in the "Code" section - is there any way to tell which local workspace that changeset came from?

Coruscate5
  • 2,253
  • 17
  • 28
  • It sounds like you should be using branches instead of separate workspaces. – Daniel Mann Jun 06 '18 at 16:22
  • @DanielMann - I don't think it's a branching issue, this is just "checking" to see if the last physical location has unchecked-in changes. I don't see how branching would resolve that concern? – Coruscate5 Jun 06 '18 at 16:25

1 Answers1

1

Sorry, it's not able to achieve this. Changesets contain the history of each item in version control. You can view a changeset to get information about:

  • which files were changed
  • what the exact changes were
  • who changed the files
  • what the check-in comment contains
  • which work items are associated with the changeset
  • which policy warnings appeared

It's not able to view the workspace info from changeset directly, even through database. A local workspace only deals with items that are stored on the local machine, such information would not be sent up to the TFS server when a changeset is committed. Take a look at this similar question: Is there a way to see the workspace of a given changeset?

You have to manually compare each workspace with server version or do the opposite-- How do I check which changeset my workspace is in

PatrickLu-MSFT
  • 49,478
  • 5
  • 35
  • 62