I have a solution on TFS "Project One".
"Project One" was copied via external to another device of mine and i needed to map the solution on the new device to source control. Once i mapped the project, it replaced all the source that was local with whatever was last on TFS for the project. Any way i can get my local source back or is it gone forever?
I had not done any backups on the local code as i didn't think it would delete my current source. In fact i thought it would as me to do a merge.
I had a look at this link after my code had been replaced
Unfortunately you've lost the changes as TFS has overwritten the local files. You set up the workspace after making the changes so TFS didn't know anything about them in order to merge.
If you created any additional files that weren't under source control then they should still exist locally, so maybe you haven't lost everything
In future, if you setup the workspace first then you can obviously make changes to the files and TFS will know about it.
Alternatively, map the workspace to a different local folder and then copy in your changes. If you are using a local workspace then TFS will generate the pending changes for you.
Had to change my computername and domain. Now I can't access team foundation. I tried this statement to fix it.
tf workspaces /updateComputerName:MyOldComputerName /s:"http://MyServer/MyCollection"
It didn't work. I get the following error "Key not valid for use in specified state."
Not sure what to do now.
It sounds like you may have a problem that will prevent remapping the workspace. However, it's possible that the command isn't quite correctly formed, so try checking the collection URL (I'd expect it to include MyServer:8080), and in versions of TFS 2010 onwards the documentation refers to /collection: rather than /s:
If that fails, then one approach to rescue things is to create a new workspace and delete the old one. You can transfer any edited files you had checked out to the new workspace as follows:
Rename your old source code folder, so you keep a backup
Create a new workspace that maps the (old) source code folder location, and Get the latest version of the code.
If you think you deleted or added files, use a folder-diff utility to find them, and manually re-do those changes.
Now check out everything (right click on the root folder and check it out)
Copy your backed up source code over your workspace folder
Undo checkout on everything. Visual Studio will ask if you want to discard your changes. Carefully choose the "No to all" option. This means it will only discard locks on unchanged files.
You will now have all changed files listed in your pending changes.
Once you're absolutely sure this has all worked, you can delete your backup of the source.
(You can achieve a similar thing by unplugging your network cable to force Visual Studio to go offline, moving your old source code back in place of your new workspace folder, then plug the net cable back in and using File > Source Control > Go Online. This should diff your code to the server and work out what changed. I don't trust this as much as the above approach though)
Once you have the code in your new workspace, you can use the tf command to delete the old workspace to clean everything up.
I'm part of a large project mapped from TFS, within that project there is a folder which I have finished working on. I don't want that folder anymore so I'd like to delete my local copy. The problem is that TFS wants to mirror the change and delete the folder from source control, I don't want to remove it from TFS.
The only way I can find to do this is to unmap the workspace, and then go through and get all the other folders I need to work on.
Is there anyway I can just delete that folder locally?
This is an older post, but since the only given answer seems "not entirely correct" to me I'd like to answer anyway:
I blogged about this (in german) here: blog.nils-andresen.de
If you have a local copy, that you want to un-get or un-download like this:
simply right-click the folder and then click "Get Specific Version" or "Advanced > Get Specific Version" and specify Changeset 1.
Here's why from Martin Woodward's TFS Top Tips:
...if you do a "Get Specific Version..." on the files, and select Changeset 1, the files will be deleted locally and the server will know this. The color of the file in the Source Control explorer will go from black to gray and will have the phrase "Not downloaded" in the latest column.
Changeset 1 is a special changeset on your Team Foundation Server instance. It was created as part of the setup routine and only contains one thing - the root node ($/) in your source control tree. If you do a get for Changeset 1 on any actual files then they will not exist at that point in time on the system so will be deleted locally and the server will know this.
When the process is complete the "Latest"-column will show "not downloaded".
After that any remaining files in the filesystem can safely be removed.
You can cloak the folder in your local workspace.
By setting the working folder status to Cloaked, you can specify that a local folder should not copy files from the server when you perform a Get operation. You might choose to do this to conserve space on your local disk. If you later decide that you need to get files in those cloaked folders, you must change the status to Active and then perform a Get operation.
Just started up Visual Studio 2012 and opened my solution which is in source control with Team Foundation Server 2012 Express and encountered this, any ideas? Can't get latest, can't check in, everything appears checked out :( Basically my workspace is unusable right now.
TF400018: The local version table for the local workspace MY-PC;My
User could not be opened. The workspace version table contains an
unknown schema version.
There is only one post I could find on the net, and the answers are pretty vague.
I had the same issue, and I just fixed it on mine.
If you don't mind re-map all your projects, you can try follow:
Click the box in "Workspace".
Click on "Workspaces".
Delete the workspace profile you're currently using
Re-connect to TFS open "Source Control"
Be aware that you may lose all your TFS mappings, you may need to re-map all your projects from TFS. Backup your changes that not checked in yet.
cycle6 is correct, but it isn't clear that you will not lose your pending check-in list if you follow some additional steps.
Click the box labelled "Workspace".
Click on "Workspaces".
Delete the corrupt workspace profile, accepting the warning.
Re-connect to TFS and open "Source Control Explorer"
Create a new workspace
One by one, map your projects to the same folder as before
You will be presented with a list of conflicts, where you have matching writable files in the folder already.
Choose "Keep local copy" for each file you had checked out before, and "Take Server Version" for any files changed by other members of the team that you didn't have the latest version for. This might take a while depending on the length of the list, but it is worth comparing versions for any file you are unsure of.
You will be left with your solution and all pending items marked as checked out, with your work preserved.
I did the following steps and it solved the issue:
deleted the hidden folder named $tfs and then
in the Visual Studio, Solution Explorer: Right click on the solution node > the Source Control > Get Specific version > latest version
If you already have multiple instances of Visual Studio open.
Close all of them . [in some cases you need to log out from windows & log back in OR restart ]
Rename the $tf folder with any other name (eg. $tft)
Start Visual Studio, to see your issue fixed. :)
Hope this helps.
Sometimes this happens when you are running out of disk space.
Try to see if you have very low space, eg. < 10 MB.
If that so, try to clean up your windows Temp folder. See if that solve this issue
It's a misleading message to an extent.
What has happened is that the internal data structures of the workspace have become corrupt.
The ends up as the code (in the tf command, Visual Studio, et al.) to load those data structures failing to load from the relevant files, which becomes an error about a schema version problem.
In the case that I experienced, this was because the machine hosting the workspace ran out of disc space while doing operations upon the workspace of various kinds (check-outs, check-ins, adding pending changes — it was actually a bunch of workspaces being used by TFS 2017 build agents and multiple active builds).
This corrupted parts of the data that are held in the files under the hidden $tf subdirectory (it always being a local workspace on a TFS 2017 build agent), because source control wasn't able to rewrite/extend these files.
Other answers here discuss partly retaining some of the files, based upon more specific knowledge of what has not been corrupted (such as preserving the internal files storing pending changes if one wasn't creating any pending changes), but the basic idea is that one needs to reset all of the stuff in $tf to a sane state of some kind.
In my case, I had the disadvantage of multiple potential causes and no consistent knowledge of which parts of $tf were corrupted, but I conversely had some advantages:
It being a TFS build, arranged to build from the build agent's s (source) directory into its a (artifact staging) and b (binaries) directories, there were not masses of non-source-controlled object and other files in the workspace (which is the s directory) that would have ended up as pending additions.
There were not any pending changes (to actual source files) worthwhile to preserve. I could afford to lose all information about source files, and indeed all current locally-stored information about the workspace, and simply run the build again with a fresh sane and largely unpopulated workspace. I did not even need to restore source files and directories for the whole workspace, as the first task in any TFS ("vNext") build is a "Get Sources" task that uses (variously) tf vc scorch, tf vc undo, and tf vc get to check out the right source version.
So simply, in Developer PowerShell (Visual Studio being installed on the build machine):
Remove-Item -Recurse -Force 'X:\Agents\07\_work\1138\s'
tf vc get 'X:\Agents\07\_work\1138\s'
(Note that one can always get at the tf command in some way on a TFS build machine. Every build agent has a local helper copy of tf.exe and its ancillary DLLs in its VSTS "OM" subdirectory.)
I possibly could have omitted the tf vc get step, but having had trouble with "Get Sources" in the past I do not trust it to robustly cope with arbitrary manual external alterations, such as no s directory when the build isn't configured to outright delete that entire directory itself (as it can be but was not here).
For the same reason, Microsoft's own "agent maintenance" (another way to clean things up) is quite dodgy, and ends up leaking workspaces on the TFS server (which I have raised a bug with Microsoft about).
There is simple workaround. Remove local mapping to folder where is the sources (Advanced -> Remove Mapping, or just rename or delete mapped folder. After that you will be able to connect to tfs. Download the project again.
If you already have multiple tfs instances of Visual Studio open.
1.) Open File -> Source Control -> Manage Workspaces
2.) Delete all tfs map
3.) Then select folder maps
For the same issue in eclipse: Find the folder $tf and delete it.
You will find the $tf folder in the workspace directory. If not then search for the $tf folder.
Once you have found it, delete it.
In my case, none of the other answers helped - the problem was occurring on a machine that didn't have Visual Studio and no matter how I tried to get rid of the bad workspace data it never worked. After working with procmon a bit, I discovered another critical folder that might be the source of this error: C:\Users\All Users\Microsoft Team Foundation Local Workspaces\ (it might also be under C:\ProgramData (on my system, 'All Users' is a symlink to that folder, but not sure if this is typical.) In this folder there are sub-folders named like guids that contain some other folders, one per workspace it appears. In my case, some of the data in these folders was old and some was corrupt. Once I deleted the bad workspace folders, all my problems disappeared. You might also want to delete the Cache folder as identified in the comments of this post, but that didn't help me (didn't seem to hurt though, either.)
Alternatively, you could just backup your current workspace to a different location, re-create your workspace, and copy the files back that you had made changed to. VS should detect the newest files and automatically check out these files allowing you to check in the newer versions that you copied back from your backup.
What worked for me is, delete the local folder(s), restart your machine, then map the projects again. Any pending changes you have just save them somewhere else temporarily.
I have several projects in TFS which visually appear in the directory hierarchy as grayed out. When I browse within the projects in Visual Studio 2010/Source Control/TFS 2010, I notice that all of their contents have a Latest value of "Not downloaded". Normally, I have only seen Latest values of "Yes" or "No".
I have tried all of the varieties of "Get latest" that I know, but I am always alerted that "All files are up to date".
If I try to "Check out for edit", I am not allowed.
When I observe the properties of these grayed out files, they always say Workspace Version = "Not applicable".
How do I fix TFS so that I can download and check out the projects again? My suspicion is that my workspace is messed up, but I do not know what to do to restore/reconfigure it.
I was able to remap the directory to fix my issue. To do this, I
selected (right-clicked) the branch that included all of my code, and selected "Remove Mapping..."
renamed the folder I was mapped to within TFS (you can delete it as well, but I renamed just to keep it during this experimental process)
created a new folder with the original name of the branch I was mapped to in the beginning, and
selected (right-clicked) the branch that included all of my code, and selected "Map to Local Folder".
This process forces a complete re-download of the entire branch. Luckily for me, my branch was only 2GB, so I was able to re-download in about 5-10 minutes.
The reason for getting "All files are up to date" - is that the information on the TFS server and the files on your disk is out of sync. If you delete the files on your disk with file explorer - the TFS server still thinks you have the file on disk. To re-sync you have to force an update like this:
Check the two checkbox on this dialog - and click Get:
It happened to me as well when I added and existing project as a reference to another project.
When I added the project reference I had a pop-up message that told me that the current project already exists at the source control but at a different location then the relative path of the current project.
by a mistake I choose the wrong option which lead to the unnecessary mapping.
In order to solve this issue I've removed the mapping from the workspace.
only after removing the mapping i could get the latest project.
I solved it by following this - remove the work space and then tfs prompted me to download everything again.
https://msdn.microsoft.com/en-us/library/ms181386(v=vs.100).aspx
It sounds like the folders / files in TFS are not mapped to a local drive in your workspace.
In Source Control Explorer, select the "Workspace:" dropdown, then select "Workspaces".
Choose your current workspace form the list that appears, then hit "Edit". Check that the TFS folder $/blah is mapped to a local folder c:\tfs\blah
You should now be able to get latest, check out etc.
I had some weirdness with this after :
updating to TFS2017
updating to VS2017
trying to change my TFS URL to https (gave up and reverted back to http)
So somewhere along the line this broke my workspace such that all my projects were showing as unbound. I was able to do a get latest again. This should not overwrite any files you have changed providing they are writable, but if you have any doubt whatsoever then backup your local workspace before doing get latest. It will ask you to resolve conflicts - so make sure to select 'keep local copy'.
In my case, when the branch was deleted: Right click + Check in, helped.