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.
Related
I am trying to move a folder in TFS 2010. After coming to grips with the fact that TFS can't do this without losing the folder's history (see this question and users' responses to Microsoft), I tried the following TF.EXE command:
tf rename Apps "Test Main\Apps"
But I get an error message.
TF10169: Unsupported pending change attempted on team project folder $/Apps. Use the Project Creation Wizard in Team Explorer to create a project or the Team Project deletion tool to delete one.
The Apps folder does not appear to have any pending changes but I tried some other folders for good measure and got the same result.
I do not want to create or delete any Team projects. What am I missing?
$/Apps is not a folder, it is the root of a team project. Think of it as "C:\". You can create folders underneath it, but it's a special entity with its own set of rules.
So, what does this mean for what you're trying to do? It looks like your goal is to rename the team project. Unfortunately, TFS 2010 does not support renaming team projects, although TFS 2015 and beyond do.
If you want to rename the "Apps" team project, you will have to upgrade to a modern version of TFS, but at a minimum TFS 2015.
Otherwise, you will have to manually create a new team project with your desired name and check in the source code. You won't be able to move it from within the source control explorer.
However, keep in mind that there is more to a team project than just source code -- any work items or build definitions will not transfer to the new team project, and there is not a mechanism for moving them.
So, your options are:
Live with the name
Upgrade to TFS 2015 or beyond (ideally the most recent version, of course)
Create a new team project
I am new at using tfs online and create projects. When I am creating a project on TFS online platform, and connecting from visual studio. So I need to map project on my disc. And I see a workspace that has same named my computer name. Does visual studio creates a workspace on visual studio for every tfs project? What is the goal of workspaces?
A workspace represents a mapping between a location in source control ($/SomeTeamProject/SomeFolder and a location on your computer (C:\SourceCode\SomeTeamProject\SomeFolder).
That's all. It's a very straightforward concept.
You can maintain multiple workspaces for purposes of isolation, or just have one workspace mapped to the team project collection root ($/), which means that every team project in the collection will be mapped in the same workspace. It's entirely up to you. The advantage of multiple workspaces is that you can explicitly avoid doing things like modifying a bunch of stuff across branch or team project boundaries inadvertently. If you have a workspace for a development branch, you'll only be able to check in a set of files in that branch. If you want to check in files in another branch, you'll have to switch workspaces. It can be a nice sanity check, but it's by no means a necessity.
Workspaces can consist of multiple mappings (for example, $/Foo/Bar -> C:\Foo\Bar, $/Foo/Baz -> C:\Foo\Baz would map those two folders, but ignore any other folders under $/Foo).
Workspaces can also contain cloakings -- explicitly excluding a folder from being mapped. So you could map $/Foo/ and cloak /$Foo/Bar if you wanted everything under $/Foo except the Bar folder.
Workspaces come in two flavors: Server and Local.
Server workspaces were the default from TFS 2005 up until TFS 2012. In a server workspace, every activity you take in source control has to happen through Visual Studio (or an equivalent IDE) -- starting work on a file contacts the server and checks the file out. Files are stored in the file system as read-only unless they're checked out.
Server workspaces are, generally speaking, awful. I do not recommend using them except for in a few very specific cases.
Local workspaces were introduced in TFS 2012 and were first supported (not surprisingly) in Visual Studio 2012. Local workspaces are slightly more Git-like in that editing files does not require an explicit check-out on the server -- you can edit a file at any time in any IDE. This allows you to work offline in a very limited fashion.
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.
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
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.