Source control is acting wierd.
Here is the scenario:
I had to reformat my computer. I backed everything up first, then blew it away. All of my backup is located on a virtual harddrive on the network, which I can connect to in order to grab what I need temporarily.
I have re-added my website / project to the same file location but now source control doesn't seem to be working.
I have made some edits which I believe the second developer does not have.
Also, the second developer has made some new edits to the website and because I am not properly hooked in to source control I cannot get those changes.
Does anyone have any ideas on what the problem could be?
Your local machine keeps a cache of the server and local workspace configuration - you will need to rebuild this cache. In addition, your Team Foundation Server workspace is tied to your original computer (workspaces are uniquely identified by your local hostname, the workstation name, and your username.) If your hostname has changed on your new computer, the server will not be able to find your existing workspace and thus it will not be able to participate in source control.
If your hostname is the same and you have copied all of your source tree over to the identical location, you should be able to simply rebuild your workspace cache on your new machine. As soon as you connect to the server (using Team Explorer in Visual Studio, or with the tf command line client) your workspace cache will get rebuild and you should have a copy of the pending changes you had on your old computer.
If, however, your workstation's hostname has changed, you can update the the hostname associated with your old workspaces. You can do this by running the command:
tf workspaces /updateComputerName:oldComputerName /collection:http://tfsserver:8080/tfs/MyCollection
Finally, you have one other option: you can simply create a new workspace and copy your changes in. You would do this by creating a new TFS workspace, getting the latest version of the code to a different directory, copying your changes over, and then detecting those changes and pending them to the server by using tfpt online from the Team Foundation Server Power Tools.
Related
I have a couple of ASP.NET Core based projects being developed using Visual Studio 2019.
I am having issues where my workspace and TFS server on Azure-DevOps are out of sync. My PC contains the most recent code and I want to push everything I have on the server. I don't really care about the status of the TFS server as it is wrong. I just want to force everything to get pushed to ensure my PC and TFS are syncing again.
How can I force the TFS on Azure-DevOps to take all my files? I don't even mind removing the project altogether from Azure-DevOps and push all files as if this is a new project.
According to your description, sounds like there is something wrong with your source control binding. Or maybe some files outside of Visual Studio do not detect by TFS server. Which cause your workspace and TFS server out of sync.
If you want TFS server detect changes done to files outside of Visual Studio, the simplest way is using local workspace.
Now anything else changes files outside Visual Studio, your workspace detects the changes automatically.
It also detects adds or deletes but you have to include them to your Pending Changes manually with the link under `Excluded Changes
If you are using server workspace, this is kind like when you are offline, you cannot work with your local files because they are read-only until you check them out. So highly recommend you switch to local workspace, you just need to make sure you open the files in VS from a path which the same as your TFS local worksapce. Then it will auto sync changes in Visual Studio and show in pending changes.
More detailed information on the pros and cons of local and server workspaces, please refer our official link.
Now in your situation, we suggest you fist back up all of your local codes/files first. Then delete your old workspace, create a new local workspace.
Get latest from your sever, then copy all your back up to your workspace folder. Then let windows file system auto detect the difference between them, replace files download from server with your back up local version.
Now your local workspace should contain the latest version of your code/file, Visual Studio will auto detect the changes and list them in pending changes, if something added in excluded list, manually promote them.
Finally you could just check in/push all pending changes to TFS server. Now everything back to the track again.
Hope this helps.
I deleted a local copy of a TFS source-code branch (actually I renamed the branch and had to delete the old-named version), but Source Control Explorer window in Visual Studio says I still have the latest version so whenever I double-click a file, I get an error that the file doesn't exist.
Is TFS supposed to notice when I delete a local working copy i.e. this is a glitch?
How can I address it? Get the latest version and then delete it?
Is TFS supposed to notice when I delete a local working copy...?
No. TFS TFVC expects that it controls your working directories, at least with a Server Workspace. When you start doing things without telling it, then it has no idea.
If you want to remove files from your local drive, do a get of changeset 0 on that path (where the files won't be) and/or delete your working folder mapping or delete the TFS workspace.
Why does it work this way? Performance. If you have 10+ GB of sources, you can't afford to have your version control system scanning your filesystem to try to figure out what you've done. That's why TFVC Server Workspaces work this way.
Change your workspace to a Local Workspace if you have only a small bit of source code and you want to scan the filesystem for changes. Or switch to Git in TFS if you want a complete distributed experience.
I have multiple solutions that were previously mapped to a hosted TFS. Their local mapping was defined as well and all the source code was up-to-date locally. I have since discontinued my TFS subscription and started using visualstudio.com as my TFS server.
I went into one of the solutions, deleted the *.vssscc files from the solution and the *.vspscc files from each nested project. When I open the solution in VS 2013, the output window gives me a message saying the the original TFS (unsubscribed now) is not available and that the solution is open offline.
As a result, when I choose the "Change source Control" option, it first asks me to log in to the old TFS whose credentials are no longer valid.
Furthermore, it tells me that the local directory I am trying to map to the new TFS is already mapped to the old TFS. How can I remove this mapping without having access to the old TFS?
Not sure if this works if you're offline, but you can remove the mapping by opening the Manage Workspaces area in Source Control Explorer (click on the ... option of the dropdown to the right of Workspace:)
Manage Workspaces -> Select your workspace -> Edit -> Remove or change your mapping.
It's probably easiest to remove the mappings using the commandline
tf workspaces /remove workspacename;owner /collection:http://urlto.old:8080/tfs/ProjectCollection
After removing the old workspace configuration for the current folder and mapping the folder to your new subscription, Visual Studio should prompt you to automatically update the solution bindings to the new server.
This will not delete your workspace from the server (which keeps track of the workspaces), but since you no longer have access to it, it should be enough to let your client forget the folder is mapped.
The answers here work when the old TFS server is available. Mine wasn't but has not been removed from the server list in VS. Removing that entry allowed me to remove the solution from source control entirely along with the mapping and add it to another source control server.
I'm having trouble setting TFS2012 to control project source files between 3-4 people.
I've been googling for 3 days, and now I'm completely lost trying to map local and server folders in workspace. So far I have managed to create a server, a project, and connect to it using Visual Studio 2010.
All I'm trying to achieve is to share one solution between this group of people, lock files for changing, and reflect those changes to server (and therefore to other people in my group) after I check in the file I made changes to...
Can someone explain how to set this up??
Workspaces are set up the clients, not the server.
So, in Visual Studio (including Team Explorer if you have only the TFS client without the rest of VS) connect to the TFS instance and select the right team project.
If VS does not immediately prompt you to create a workspace (it's been a while since I did this on a refresh install) go to File | Source Control | Advanced | Workspaces...
There you can select or create a workspace (remember workspaces are specific to the combination of user and computer). Once you open a workspace to edit you can create mappings between source control paths and local paths.
NB. in the workspaces dialogue you can select "Show Remote Workspaces" to see other users' and computers' workspaces and copy mappings to paste into another.
Recently I have been working on a project and have been waiting to publish it to Azure. Before I was able to do this my local user account on my machine was changed. Now when I try to add the project solution to the solution control explorer I get "access to path [old username]/my documents/projects is denied." I have the project copied from the old user account onto the new one I am using. I opened from this location, but it still seems to reference the old path. How do I change this and/or what settings do I need to change?
I have uploaded the project into the source control explorer for the project, and the rest of the team can view it. It is possible to re-load the project from here and create a new work space mapping on the new local account? If so how can I do this?
I managed to get it moved by doing the following, thanks jessehouwing for the push in the right direction.
Closed Visual Studio
Went to old account, copied project directly to the C drive
Went to the new account, opened the project from there
Deleted mapping referenced in the picture in jessehouwing's answer
Created new mapping under a different name, because even though the old one was removed, there was still a naming conflict (I have no clue)
Mapped the source control and local folder from scratch
You will have to change your workspace mapping. If the Source Control Explorer allows you, you can open the Workspace dropdown (in the toolbar) and edit the current mapping.
If the Source Control Explorer doesn't allow you due to Access Denied errors, you can also use the commandline utility tf.exe to remove them.
tf workspaces /remove
And then create a new one through the UI or also from the commandline using
tf workspace /new
tf workfold /map
I'm re-using an old picture here, step 4 should be to fix the paths in the Workspace folders list on the bottom of the dialog :).
This is still happening in 2022 and below are steps we have resolved this "Access Denied" in visual studio (2019 in our case) for Azure DevOps Server.
Open visual studio command line and run the command;
tf workspace /delete “WORKSPACE_NAME;OWNER”
Open folder C:\ProgramData\Microsoft Team Foundation Local Workspaces and delete anything folder inside
Verify C:\ProgramData\Microsoft Team Foundation Local Workspaces
folder has the user you are logged into the machine as full access
Go back into Visual Studio and reestablish your workspaces and
perform a get latest