Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

TFS deleted my files when changing the mapping

I had quite a big solution with a lot of code here. Because of some issues with TFS I wanted to create a new 'clean' repository. I removed the mapping to the old repository, and tried creating a new mapping. This resulted in an error that there already was a mapping to my solution. I went to the Source Control Explorer -> Workspaces and deleted the mapping to my solution there. After that I was able to map my new repository to my solution.

But when I checked my hard disk I almost had a heart attack: TFS deleted ALL my code files! The directories and dependencies were still there, but all my project files, my solution file and all of the code was gone!

Please StackOverflow, help me out here! This is a LOT of work that is now gone and I really desperately need it back :(

Edit: I'm currently trying to recover my files with a couple of file recovery tools (like Recuva), but none of them can find any deleted changes. But the files are really gone, Windows search doesn't find them, and they aren't hidden either. Can anyone tell me why this is? Are the files still on my SSD then?

like image 563
Leon Cullens Avatar asked Mar 25 '23 03:03

Leon Cullens


1 Answers

Source control systems like TFS all work along very similar lines. They treat the server's version of the code as "the code" - it's the master copy, and is "owned" by the server. You can then get a copy of the code on your PC (by adding a workspace mapping you tell it where you want it to put this copy). You can make changes to your copy of the code, and then check them in to apply them back to the master version of the code on the server.

So if you change a workspace mapping (e.g. change the location of your copy of the code from folder A to folder B), what you are telling the source control system is "please take away the copy of the code that is in location A, and put it in B". So this is why it deleted all "your" code. It wasn't "your" code, it was a copy of the server's code - you asked it to put it somewhere else on your PC ... so it did.

However, if you had edited any of the code in your workspace, the files would have been checked out, in which case TFS would have known that you had pending changes, and it shouldn't have deleted those files - it should have reported an error as you were trying to change a workspace mapping that included pending changes.

The only way this wouldn't happen is if you manually changed the files to be writable and made changes to them outside of Visual Studio/TFS, so that TFS did not know you had made the changes. If you "secretly" changed some files, TFS may have thought they were unchanged, and therefore permanently deleted them. These files may not show up in file recovery tools because by asking TFS to relocate the workspace you got it to delete the files and then immediately re-get them (into a new folder), which will almost certainly have overwritten the data of the deleted files.

If your changes might have been checked in, then you can find them like this: go to your Team Project in the TFS Source Control view. Right click the Project and choose the "View History" option. This will list all checkins to the project in reverse historical order - if you checked in, then you should see your checkins here. (You can double click any changeset entry in the history to view the list of files that were changed, and if you right click any file you can "Compare..." to see a diff that illustrates exactly what changes were made)

If the changes are not in your checkin history, then I'm afraid you've lost them.

You've probably already learned this, but it's important to learn to use tools like source control properly - they are useful and powerful tools, but they can be dangerous if you don't understand how they work.

like image 73
Jason Williams Avatar answered Apr 24 '23 00:04

Jason Williams