Moving local workspaces between users VS2019/TFS [Self Hosted/ Azure Devops]
Tags: visualstudio, dotnet, devops, windowsterminal
Published: 2021-03-17 08:28:29

---
title: Moving local workspaces between users VS2019/TFS [Self Hosted/ Azure Devops]
published: true
date: 2021-03-10 09:13:49 UTC
tags: VisualStudio,dotnet,DevOps,WindowsTerminal
canonical_url: https://yer.ac/blog/2021/03/10/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 

#### 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 

You are logged into VS2019 with your new user that you 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**. I will also be using Windows Terminal to launch this, as per the guide in [Adding VS Developer Command Prompt To Windows Terminal (VS 2019)](https://dev.to/wabbbit/adding-vs-developer-command-prompt-to-windows-terminal-vs-2019-44pg-temp-slug-8547805).

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

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.

![](https://i1.wp.com/yer.ac/blog/wp-content/uploads/2021/03/image-4.png?fit=700%2C159&ssl=1)

## 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.

![](https://i0.wp.com/yer.ac/blog/wp-content/uploads/2021/03/image-5.png?resize=577%2C246&ssl=1)

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

## 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.

![](https://i0.wp.com/yer.ac/blog/wp-content/uploads/2021/03/image-2.png?resize=514%2C104&ssl=1)

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`

#### 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.

#### 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` (You can also do this in VS)
- 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` 

## Alternatives

There is a GUI based tool called [TFS Sidekicks](http://www.attrice.info/cm/tfs/) – 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.

The post [Moving local workspaces between users VS2019/TFS [Self Hosted/ Azure Devops]](https://yer.ac/blog/2021/03/10/moving-local-workspaces-between-users-vs2019-tfs-self-hosted-azure-devops/) appeared first on [yer.ac | Adventures of a developer, and other things.](https://yer.ac/blog).