Moving local workspaces between users VS2019/TFS [Self Hosted/ Azure Devops]

Whilst I use GIT for most my source control these days, I still have some projects in TFSVC. On a recent switch of Visual Studio accounts I temporarily lost access to my mapped workspaces as these are linked to the VS logged in user, rather than to the machine. This post will show migrating a workspace to another user.

There are 3 scenarios covered here:

• Accessing a remote workspace for another user including any pending changes
• Migrating a workspace with no pending changes
• Migrating a workspace with pending changes

Note that depending on your setup and situation, you may need to access the workspace remotely first (by making it public), shelve any changes, and then migrate the workspace.

The low effort approach instead:

If you don’t have many mappings, and have access to your old workspace still. Simply shelve any changes, map the new workspace and then unshelve the old users changes to your new workspace – all in VS. No need to read on.

Prerequisites

We are logged into VS2019 with the new user that we wish the workspaces to belong to.

I am assuming that the workspaces exist on the current machine. If not you will need to use the tf command for setting the computer name to your current machine first.

This will be using the VS Developer Command Prompt. You can launch this from Tools- > Command Prompt in VS, or be fancy and use Windows Terminal to launch this, as per the guide in Adding VS Developer Command Prompt To Windows Terminal (VS 2019). (The latter is totally optional)

You will (Or we did) need to run these commands on the users machine, as although the remote update call succeeded it didn’t actually appear to have changed the workspace. YMMV.

YMMV, but we found with some users, having the same workspace name on both sides caused issues. If you have a workspace (Which are usually named automatically) in your new user, you may want to rename it first.

You will also need permission to administer workspaces. In Azure DevOps this is at organization level under repos, as below. Note that this is a global permission so ensure any commands are scoped to a particular user or workspace as there is no revert.

Accessing your old workspace (Pending changes intact)

If you don’t need to migrate, but simply need access you can do this by making the workspace public with the command

tf workspace /collection:https://domain.com "WorkspaceName;UserName" /permission:Public

This will display the VS popup for editing a workspace. From what I can tell this has to be done on the machine that contains the mappings(?). Press OK. If OK is greyed out, you do not have appropriate permissions.

You may need to restart VS, but should now see an accessible remote workspace which you can work against.

If you want to convert this to a local workspace you will need to shelve any changes, and follow the instructions below.

See Common Issues below if you have any errors.

Migrating workspaces

Locating workspaces

Launching the VS Developer Command Prompt and executing the command tf workspaces will display the workspaces that are accessible on the system, but not necessarily the logged in user.

Use this to get the name of the collection, and the workspace. You can also run the command below if you want to view for an owner which is not yourself, or the workspace is remote. (replacing owner and collection as appropraite)

tf workspaces /owner:olduser@domain.com /collection:https://your-collection.com

See Common Issues below if you have any errors.

Migrating (Workspace has NO pending changes)

Run the command below, replacing the workspace name, user and

tf workspace "WORKSPACENAME;OWNER@DOMAIN.COM" /newowner:newowner@domain.com /collection:https://domain.com /noprompt

This should attempt to migrate. If you have no pending changes this should resolve successfully. See Common Issues below if you have any errors.

Migrating (Workspace has Pending changes)

If you attempt the above but have pending changes you will get:

TF14006: Cannot change the owner of workspace WORKSPACE;USER to NEWUSER because the workspace has pending changes. To change the owner of a workspace with pending changes, shelve the changes, change the workspace owner, and then unshelve the changes

If you have access to the old workspace, shelve the changes and undo any checkouts and retry. If you do not have access, then continue reading.

For this I coud’n’t find a CLI route that allowed me do this fully remote. This is a bit convoluted but MSDN didn’t show any commands for executing this fully remote.

• Follow guide above for “Accessing your old workspace” to get the remote workspace and ensure its mapped locally.
• cd into any directory which is under that workspace.
• Running tf status should display what changes are made to that workspace.
• Now shelve this with: tf shelve "Migrate" /move /recursive /noprompt
• Running tf status now should yield no changes and running tf shelvesets should show a single “migrate” shelveset.
• Migrate the workspace with tf workspace "WORKSPACENAME;OWNER@DOMAIN.COM" /newowner:newowner@domain.com /collection:https://domain.com /noprompt
• In VS you should now see your workspace. Unshelve in VS, or run the command tf unshelve migrate /noprompt
• See Common Issuesbelow if you have any errors.

Alternatives

There is a GUI based tool called TFS Sidekicks – Although I have not tried it it comes highly recommended on various posts.

Common issues

TF14045: The identity [user] is not a recognized identity.

In this scenario, make sure you are defining the login rather than the Owner name – i.e. me@mydomain.com or DOMAIN\USER vs John Smith.

You are not authorised to access <url> / TF30063 / User is incorrect in TF prompt

First -in the prompt-, find out which user is being used to run the command, with tf settings connections . This will show the connections and the associated user. If this is blank or incorrect you will need to switch users with the command tf settings connections /switchuser https://domain.com which will display the MS sign in dialog.

Workspace unmapped after restarting VS

We only saw this once, but the issue (we think) was linked to the workspace having the same name on both users (As TFS auto generates these based on the machine name IIRC), or that the command prompt was running under the wrong user. See above for ensuring the user is correct for the collection, and perhaps rename any auto-created workspaces on your new user.