1

I have 2 accounts to my Azure Devops TFS repository. I only really use one of them. Yesterday I accidentally signed in with my other account and now it has taken over my workspace somehow. All my pending changes are gone and my source control bindings. I have backed up my source and can do a winmerge diff to find my changes but I cannot delete or change ownership of the workspace as it keeps coming back after deletion. I repaired my VS 2020 installation and that other account is signed out but every time I create a new workspace the owner is the other account. Please help.

Update: So I tried to repair the VS installation in hope that it would reset everything but it did not work. I uninstalled Visual Studio completely, also did not work. These workspaces will not disappear. Visual Studio hangs and crashes around 50% of the time now when I start it up. If I cannot resolve I know reinstalling my Windows will fix it but that's a bit dramatic. Hoping someone knows how to 'reset' further than an uninstall.

Shumii
  • 4,529
  • 5
  • 32
  • 41
  • I moved, then deleted my TFS repositories for a git solution(s) in AzureDevops. If these are your *personal* repositories, a similar approach might be time efficient in the long run. Also git handles individual credentials in more localalized fashion, so this could not happen via git clones. – ΩmegaMan Jan 11 '22 at 23:20
  • 1
    Workspaces are **not** a Visual Studio concept, although you can manage them via Visual Studio. You can manage your workspaces via the `tf` CLI (refer to the internet for more documentation), which will provides you with better tools to troubleshoot, diagnose, and repair the issue. – Daniel Mann Jan 12 '22 at 01:27

2 Answers2

0

I will not accept this answer but I think its worth posting as it was my only sure way of resolving within a known timeframe. I am sure there is a better way but if someone finds themselves desperate, this is a way out.

I reinstalled Windows 11 with option to delete all my files. When I reinstalled Visual Studio 2022 I was shocked to see the workspace back again. Clearly it got this from the server so I used some tf CLI commands (thanks @DanielMann)

tf vc workspaces [workspace] /computer:* /format:xml collection:https://[collectionurl]
tf workspace /delete [workspace];[userid]

to delete these and this time round they never came back. I have used the tf commands prior but the workspace kept coming back.

Not an ideal solution but I keep my dev laptop quite light and everything can go. The reinstall took like 20 mins, plus another 30 to reinstall software compared to the whole day I lost yesterday.

Also worth mentioning I had previously used tf commands to get all the workspaces outputted in xml so I could specify the workspace and userid. Tried a bunch of other ways to delete the workspace also but nothing would work.

Reinstalling Windows AND removing workspaces from server ensured the workspace never reappeared.

Be also worth nothing that at this point I no longer cared about the workspace but whatever happened caused my Visual Studio 2022 to no longer function correctly even after a reinstall. It would hang and crash all the time and this now fixes it (as you'd expect with a reinstall of OS).

Shumii
  • 4,529
  • 5
  • 32
  • 41
0

My guess would be that a

tf vc workspace /newowner:rightuser workspacename;thewronguser /collection:https://server/collection

Or

tf vc workspaces /updateUserName:rightusername workspacename;thewrongusername /collection:https://server/collection

Would have done the trick.

The server keeps track of the workspace ownership. Every time a workspace is created locally it's registered on the server. Originally so it could track what files were checking out and/or locked (server workspaces) and with local workspaces basically only what folders are mapped on your computer to prevent the creation of overlapping workspaces on the same computer.

I haven't heard of automatic hostile takeovers of workspaces when you are signed in with the wrong user account, but to revert the change you should tell the server who the rightful owner of the workspace is. Thin sign back in with the correct username.

The fact that a Windows reinstall worked is likely because it would have deleted the local workspace cache on in your user profile. The deletion of the workspace on the server (with the commandline) would have freed up the paths on your computer so you could map these folders again. Had you entered a different machine name, that would have solved things too.

See also:

jessehouwing
  • 106,458
  • 22
  • 256
  • 341
  • Thanks but unfortunately I cannot try it now its resolved. What I can say is that I tried those commands minus the ‘vc’ and it did not work, it kept coming back. In visual studio the ownership of the workspace would change when I run the commands, but they would change back when i restart visual studio or connect to source control. All new workspaces would also be wrong owner. Furthermore, visual studio became usably unstable. Going to source control explorer would crash 50% of time. – Shumii Jan 13 '22 at 10:09
  • What can I say. TFVC is pretty dead. – jessehouwing Jan 13 '22 at 10:22