Related
I migrated TFS from an old server "OLDMACHINE" to a newone "NEWMACHINE". TFS is shutted down on OLDMACHINE. Now I want to update my different URLs on developpers computers.
For my git clones, the command is :
git remote set-url origin https://NEWMACHINE/...
I don't find the corresponding command with tf workspaces. I've search in the Visual Studio's window Workspaces..., but I can't open it anymore because my old TFS is down.
The next command show me my workspaces :
tf workspaces
Is it possible to update the URL with
tf workspace ?
There are many documentations about renaming computer, moved folder, username, but I didn't find any in my direction.
EDIT :
I found this key in regedit, with subkeys. I want to give it a try, has anyone ever done this manipulation?
HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\12.0 or 14.0\TeamFoundation\Instances\OLDMACHINE
There is no this kind of related command for TFVC. Each TFS server has a unique identifier(GUIDs) that is used to represent each collection and is not dependent on the server "name." The upgrade/migration does not modify the TFS GUIDs.
For that reason, all end-users have to do is connect to the TFS server via Visual Studio and can resume work, including any pending changes. No need to update the "collection name" for their local workspace.
Besides, if you have problems with workspaces, TFS Sidekicks is a really useful tool because it gives you a nice GUI tool to list, check, delete and manage all workspaces defined in your TFS. (Need Administrative privilege)
I had a project in tfs within a team project then we moved the project to a different location in another team project.
I had configured Jenkins to connect to the team project and build my solution but when I changed the settings to connect to the new tfs team project, it gives me the below error:
[workspace] $ "C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\tf.exe" workspace -new Hudson-ProjectName1-Build-MASTER;domain1\username1 -noprompt -server:http://domain-eg.net:8080/tfs/newteamproject ********
The path D:\jenkins\jobs\ProjectName1-Build\workspace is already mapped in workspace Hudson-ProjectName1-Build-MASTER [http://domain-eg.net:8080/tfs/oldteamproject].
So the above shows that there is an existing workspace so I ran the below command to remove it
tf workspace -delete Hudson-ProjectName1-Build-MASTER;domain1\username1 -noprompt -server:http://domain-eg.net:8080/tfs/oldteamproject
and it prompted that the workspace has been removed but I'm still getting the same error.
I also checked whether the mapping has been removed or not by running the below command:
tf workspace -server:http://domain-eg.net:8080/tfs/oldteamproject Hudson-ProjectName1-Build-MASTER
but it says the workspace doesn't exist as expected.
So, I thought it might be caching it somewhere and ran the below command:
tf workspaces /remove:* /collection:http://domain-eg.net:8080/tfs/oldteamproject
and it said "No workspace in the cache matches * from server http://domain-eg.net:8080/tfs/oldteamproject"
so I'd guess it's not even cached.
So what's causing the error and how to resolve it?
From VS:
Open Team Explorer
Click Source Control Explorer
In the nav bar of the tool window there is a drop down labeled "Workspaces".
Extend it and click on the "Workspaces..." option (yeah, a bit un-intuitive)
The "Manage Workspaces" window comes up. Click edit and you can add / remove / edit your workspace
From VS on a different machine
You don't need VS to be on the same machine as the enlistment as you can edit remote enlistments! In the dialog that comes up when you press the "Workspaces..." item there is a check box stating "Show Remote Workspaces" - just tick that and you'll get a list of all your enlistments:
From the command line
Call "tf workspace" from a developer command prompt. It will bring up the "Manage Workspaces" directly!
I ran into the same problem, and was able to fix it by manually deleting all the files in the TFS cache, located here:
%LocalAppData%\Microsoft\Team Foundation\3.0\Cache
or 4.0, 5.0, etc.
Follow these steps to remove mapping from TFS:
Open team explorer
Click Source Control
Right click on you project
Click on Remove Mapping
The error is genuine. You might have created workspace with same name on different machine. Now you may have changed machine having different machine name.
So here is work-around that will definitely work.Following is work-around.
Go to "Team-Explorer"
Go to "Source-Control"
Go to Workspace drop-down
Click on "Workspaces..."
A pop-up window will appear
Click on "Show remote workspaces"
Now delete the workspace which is conflicting and you can proceed your work.
Please follow the below steps:
Ctrl + Run
Copy and Past
%LocalAppData%\Microsoft\Team Foundation
You will get different version of TFS e.g
Click on each folder and you will get
Now Delete all data in these folder.
Reopen the Visual studio.
Thanks.
All of the answers here seem to be partial answers that don't work in all cases. I think this answer will work in all cases, assuming you have proper permissions.
Open up the Developer Command Prompt. In my case, I've tested this with the Developer Command Prompt for VS 2019.
Type this command: tf workspaces
Note that the results can list a couple tables with identical structure. If you only see one table, then some of the assumptions in the other answers can work for you. However, if you see two or more tables, then that Collection string is important! For our examples, we're going to assume you have two Collections (two is no different than four other than one is more tedious than the other to go through it):
https://dev.azure.com/foo and https://bar.visualstudio.com/
With luck, you will know which one of these two you want to work with. However, if you need to cycle through them all, then you'll just have to do that one collection at a time. Each "Collection" here is the same as an "Organization" in Azure DevOps (I think).
If you don't use this Collection detail, then you might see an error message:
Unable to determine the source control server.
Next, type this command for the collection you want to use:
tf workspaces /computer:* /owner:* /collection:https://dev.azure.com/foo
This will give you a much more complete picture of what you're dealing with. This gets especially nasty if you have had multiple MSAs and Org accounts hitting this repo from the same computer. In fact, you might have multiple seemingly-identical entries. If you try to delete them based on what you currently know, it may not work. But we can get more information.
Next, we're going to run the same command but append /format:xml to the end of it:
tf workspaces /computer:* /owner:* /collection:https://dev.azure.com/foo /format:xml
This now gives you a bunch of XML with some additional properties. The ones that we likely care about the most are the Owner Aliases. This is the missing information you need to now go through and delete these workspaces. Without this additional information, it's easy to hit a wall and be stuck with an error message:
Specify one workspace.
Now we have all of the info we need. Given the additional OwernAliases entries, select the unique entry (or repeat if more than one) that you wish to delete and use this following command (a couple examples are listed):
tf workspace /delete /collection:https://dev.azure.com/foo
"MyWorkspaceName;Windows Live ID\John.Doe#hotmail.com"
tf workspace /delete /collection:https://dev.azure.com/foo
"MyWorkspaceName;John Doe"
tf workspace
/delete /collection https://dev.azure.com/foo
"MyWorkspaceName;2C3E8474-A39C-4785-8794-DC72F09981E6\John.Doe#Example.com"
The GUID identifies an AAD directory and the quotes are there to handle any spaces that might be in an alias. The "MyWorkspaceName" comes from your previous queries listing out the workspaces.
Without this very thorough approach, it's possible that all of the other answers in this question will fail for you. While some of those efforts will clear out local workspaces, they will not clear out server workspaces, which you can still conflict with. Additionally, if you have previously used a different account things can get hairy, like if you switched from an MSA to an AAD account. And things get REALLY hairy if you have an MSA account and multiple AAD accounts all with the same email address that you have used from the same workstation. And then it gets super crazy hairy if multiple of those all used the default name for the workspace: your computer's hostname. In my case, I had four workspaces all with the same Workspace name, Owner name, and Computer name (i.e. the first query without the XML formatting had 4 identical records!).
I do not know if there's a more graphcial way to manage these than this. I have looked and not yet found a better way than this.
Update 2019-01-23
If you’re repeatedly getting the following error The workspace wkspaceEg does not exist… even after employing the correct username (wkspcOwnerDomain\wkspcOwnerUsername) in the tf workspace command, e.g.,
tf workspace "wkspaceEg;wkspcOwnerDomain\wkspcOwnerUsername" /collection:http://tfs.example.com:8080/tfs/collectionEg /login:TFSUsername,TFSPassword
then the tf workfold command may help fix it. See this question.
If even that doesn’t work and you’re unable/unwilling to use TFS Sidekicks, proceed to the risky last-ditch option below.
I’m using TFS 2012. I tried everything that was suggested online: deleted cache folder, used the workspaces dropdown, tf workspaces /remove:*, cleared credentials from Control Panel, IE, etc.
Nothing worked, I believe my workspace got corrupted somehow. Finally, I went to the TFS database and ran the following queries. That worked! Of course be very careful when messing with the database, take backups, etc.
The database is called Tfs_<<your_TFS_collection_name>>. Ignore the Tfs_Configuration MSSQL database. I'm not sure but if you don't have a Tfs_<<your_TFS_collection_name>> database, settings might be in the Tfs_DefaultCollection database. Mapping is stored in tbl_WorkingFolder.LocalItem.
/*Find correct workspace*/
SELECT WorkspaceId, *
FROM tbl_Workspace
ORDER BY WorkspaceName
/*View the existing mapping*/
SELECT LocalItem, *
FROM tbl_WorkingFolder
WHERE WorkspaceId = <<WorkspaceId from above>>
/*Update mapping*/
UPDATE tbl_WorkingFolder
SET LocalItem = 'D:\Legacy.00\TFS\Source\Workspaces\teamProjEg' WHERE
/*LocalItem = NULL might work too but I haven't tried it*/
WorkspaceId = <<WorkspaceId from above>>
Team Explorer > Source Control Explorer >
I managed to remove the mapping using the /newowner command as suggested here:
How can I regain access to my Team Foundation Server Workspace?
The command opened an Edit Workspace windows where I removed the mapping. Afterwards I deleted the workspace I didn't need.
None of the answers here removed my workspaces. But here is one solution that may work for you.
Open up a Visual Studio command prompt
Close Visual Studio first or the delete command may not delete the workspace
List the workspace commands -> tf /? to find the commands available to you from the version of TFS.
List the workspaces -> tf workspaces
Delete the workspace -> tf workspace YourWorkspace /delete
You don't have to delete the entire Cache folder. you lose all settings / preferences
The workspace mappings are stored in a file called:
VersionControl.config under the users local settings/application data directory.
located here in windows 7:
%LocalAppData%\Microsoft\Team Foundation\x.0\Cache\Volatile
where x= 3.0,4.0, 5.0,6.0 etc.
Inside this you will find guid named folders , open each of them, manually editing the forementioned file, to remove the workspace mapping(directory path will be present in mappedpaths attribute) from that local folder to the TFS server (which is no longer in usage).
File -> Source Control -> Advanced -> Workspaces -> Choose the workspace in Manage Workspaces and click "Edit" Then you can change the local folder.
Finally deleted ALL workspaces and started from scratch. Fixed.
I was prompted to login to our TFS server via Visual Studio, so I used my SU account which is typically required for server access. This led to some issues, and I ended up mapping to a different folder, not realizing I had just duplicated all my stuff. At some point, Visual Studio reverted back to my regular user, I "lost" pending changes, and noticed that new pending changes were placed by in my old mapping.
When I would try to remap to the new location (that the SU account was linked to) in an attempt to recover my pending changes, it would tell me it was already mapped to the SU, and I couldn't do that, but had no way of removing the map! Show remote workspaces, removing all workspaces via command line, etc revealed nothing. I then thought "what if it's actually linked to the SU user account on my computer, not the domain." I logged in as my SU locally, and sure enough, there was a workspace all setup for that user. I removed the mapping, and was able to go back to my regular user and remap without issue.
Moral of the story, perhaps another user is logged in on the same machine, which isn't visible from the currently logged in user, thus you cannot remove or even see the mappings.
If the mentioned clues are not helping you then download Team Foundation Sidekick and using that you can delete the workspaces.
Following are the steps to remove mapping of a project from TFS:
(1) Click on View Button.
(2) Open Team Explorer
(3) Click on Source Control
(4) Right click on your project/Directory
(5) Click on Remove Mapping
(6) Finally Delete the Project form local directory.
You can also remove a tfs mapping by simply editing your .sln file and removing the GlobalSection element for the tfs binding.
Thanks for your help!
Find problem workspace
SELECT * FROM tbl_Workspace
WHERE WorkspaceName like '%xxxxx%'
Find desired workspace
SELECT * FROM tbl_Workspace
WHERE WorkspaceName like '%zzzzz%'
Select Edit Top 200 tbl_WorkingFolder then Find the problem mapping
SELECT * FROM tbl_WorkingFolder WHERE WorkspaceId = Problem WorkspaceId from above
Change the WorkspaceId to the desired WorkspaceId
Finally goto Project Explorer and select Remove Mapping on the project
Modify VB6 MSSCCPRJ.SCC to match the desired WorkSpace
First download and install Team Explorer plugin in your system and then go to the Source Control Explorer. In the navigation pane find the Workspace field and click on Workspaces option.
After clicking on Workspaces option, you will see all the workspaces that are mapped. Click on the remove button and the remove the mapping for required workspaces.
Run tf workspaces to view current workspace mappings. Output looks like:
Then run tf workspace /delete "{workspace};{user}
Using output above, to delete workspace bi:
tf workspace /delete bi;James Wierzba
If mapping is proper then you can undo/checkin your changes, if you really want to change folder name.
Alternatively if you want to remove mapping then in Visual Studio go to
File-> Source Control-> Advanced-> Workspaces-> Edit
Now you can click on appropriate path and remove mapping.
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.
Running VS 2010, I want to now build on TFS 2010.
Originally I connected TFS server "tfs1". Now I want to map my local path to new TFS server "tfs2".
How to disconnect my old mapping with tfs1?
I got an error:
The path C:\test\xxxAdmin is already mapped in workspace aaa-PC[http://tfs1:8080/tfs/windowsapp]
Thanks.
In the source control explorer for your old server, you can drop down the "Workspaces" list, choose "Manage workspaces," and delete the workspace you no longer want to use.
Most of the time you can go to the directory in question ("C:\test\xxxAdmin") in a VS command window (Start->All Programs\Microsoft Visual Studio 2010\Visual Studio Tools\Visual Studio Command Prompt (2010)) and then enter "tf workspace". Unless things are a bit screwy this will bring up the GUI "Edit Workspace". Find the directory in the "Working Folders" list, select it, and click "Remove".
You should now be able to create the new mapping
Select Manage workspaces and delete the workspace that you don't need.
You can also use tool Tfs Workspace
We are just in the process of migrating our TFS repo to Mercurial as we've had enough of TFS. Unfortunately TFS has thrown us one last curve ball before it lets us go. We've wrote a script that we intend to have "get" each changeset (including timestamp, check-in comment etc) and then add them to the Mercurial repo and check it in.
Unfortunately TFS is acting very strange when we execute the tf get * /version:C111 /overwrite command. It immediately returns "All files are up to date." But this is impossible. The workspace folder is empty! And viewing the details for the 111 changeset quite clearly shows that the changeset contains "stuff" i.e. the repo is certainly not empty.
What could be causing this?
TF will return "All files are up to date" if the itemspec you pass in is not found. If you don't include an absolute path, a relative path is assumed.
For example if you send
tf get myFile.cs /version:1009 /force
it looks in the current directory for myFile.cs, which doesn't exist, so it returns "All files are up to date." What we really want is
tf get C:\myproject\myFile.cs /version:1009 /force
Same thing with wildcards, eg
tf get D:\project\* /version:C111 /overwrite
Check out the itemspec link for more info.
You should try /all instead of /overwrite, this will force it to get all files, not just the ones it remembers getting to this workspace on the previous get.
MSDN Reference for Get
Instead of "Get latest version", you can "Get specific version" of type "Latest version" and check the "Overwrite all files even if the local version matches the specified version" checkbox. That will force a get latest.
I've had this same issue before, and after pulling my hair out, the only thing that corrected it for us was to un-map the workspace, delete all the local files, and then remap the workspace to disk - TFS would finally get a fresh copy of the files then.
We were using TFS 2005, for what it's worth - I'd be sad to hear that this situation still arises with newer versions. If you find another solution, please post it here, as I'd love to know how you resolved it.
I tried with /force, /recursive, /all options and still had the problem ("All files are up to date.") Eventually I realized the problem was due to mapping. So I deleted mapping and recreated.
My old mapping (incorrect) was done with a wildcard:
tf workfold $/* C:\DEV
So when I listed work folders (tf workspaces /format:detailed) it showed up like this:
Working folders:
$//*: C:\DEV
When I remapped as below, the get command started working:
tf workfold $/ C:\DEV
and the mapping was showing like this:
Working folders:
$/: C:\DEV
This can happen if you do not have adequate permissions to the source. I was able to see the entire source tree, all files, but I could not get the most recent version. I guess this is permission flexibility taken to the extreme (absurd?). To verify the issue was not workstation or mapping related, I tried looking at a code file on the team pages and received:
Image demonstrating lack of access to source file
I just had to fix this problem:
Get Tfs power tools. You can also get it from tools > Add-in manager inside visual studio.
It will require you to close visual studio to complete installation.
Once complete, open a command prompt in admin mode.
cd to your branch/solution directory.
run tfpt scorch (tfpt.exe comes with the power tools, if you don't see it, reinstall)
If it finds stuff missing, it will open up a dialog. Just hit next or ok and it will overwrite anything that does not match the server.
You can always add the "/force" parameter to TF GET to force it to get all files regardless of what it thinks you have in your local workspace (it maintains the versions of all of your workspace files on the server).
It looks like there are multiple ways to trigger this issue. In my case it was dealing with passing a relative path to a script that generated an absolute path and then passed that path to tf.exe. This is a Windows scripting problem more than anything else, but output from tf.exe is confusing.
Really what you'd like to see tfs return is "File not Found" instead of "All files are up to date".
In addition to the other suggestions made here, also double-check what you're passing to tf.exe by re-writing the command with echo first. If you're coming from a unix/linux background, string building just seems broken on win32.
broken.bat
SET PARAM1=%1
SET CMD_PATH="c:\path\to\%PARAM1%"
echo %CMD_PATH%
Result: broken.bat "tool.exe" => "c:\path\to\"tool.exe""
fixed.bat
SET PARAM1=%1
REM Strip quotes: http://www.dostips.com/DtTipsStringManipulation.php
for /f "useback tokens=*" %%x in ('%PARAM1%') do set PARAM1=%%~x
SET CMD_PATH="c:\path\to\%PARAM1%"
echo %CMD_PATH%
Result: fixed.bat "tool.exe" => "c:\path\to\tool.exe"
Check your workspace. I went to delete it as above (which probably would have fixed it as well) but I noticed that someone a project within my project got it's own workspace assigned in addition to the overall workspace. I removed that project from the workspace and it downloaded all my files when I clicked ok to exit the workspace menu.
My problem was that I was running VS developer command prompt from VS 2012 studio but my workspace mapping is inside vs 2013.
Make sure you run tf.exe from inside of visual studio directory which has workspace mapping, than simple tf.exe get "path" /all /recursive works just fine
Choose a date in future to get specific:
tf get * /version:D01/01/2099 /recursive /force /noprompt
Also make sure you have rights on the team project site in your project collections.
In my case, I could see the project folder and branches in TFS source control explorer, but I couldn't access the project's TFS website.
Instead of returning an error detailing a permissions issue, VS instead said all files are up to date when I tried to get the latest version.