I have a workspace where I want the repository root mapped to a particular folder (e.g., $/ mapped to D:\Home). This then picks up the default "natural" folder structure in the repository without having to map stuff manually.
There's a pair of subprojects that I had under the default TFS structure and were recently moved around under another folder. TFS helpfully remembers that those were pointed to a particular location on my hard drive, but what I need is for them to lose the (now) custom mapping and simply go back to picking up the default mapping location based on where their parent folder points to.
I can see an option to remap the folders, but no option to simply drop the custom mapping. IIRC Visual Source Safe had a way to do this -- to just stop mapping a folder in a custom way and return it to being mapped by default based on its parent folder. But I can't figure out if TFS can do that as well...
If it makes any difference, this is TFS2005 being used from VS2010.
EDIT
Here's an example to make this clearer. Say $/ was mapped originally to D:\Home. So $/Foo would map 'naturally' to D:\Home\Foo. $/Foo/Widget was also mapped naturally to D:\Home\Foo\Widget. Then Widget was moved from under $/Foo to $/Bar, but TFS is still telling me that the mapping is to D:\Home\Foo\Widget, when I want it to be D:\Home\Bar\Widget. I want to remove the custom mapping and let Widget be mapped to the 'natural' location under its parent folder, not point to the older location.
I think I understand what you are trying to do.
How did you move that widget? Did you use TeamExplore -> Source Control Explorer to move it? If not...
Open Source Control Explorer -> Go to your widget and right-click -> Move (Option is directly under Brancing and Merging)
You will see a dialog with a From and To box. Browse to the new location on your HDD and move the widget.
In this way, TFS will pickup the new location correctly and it will be naturally mapped again. Anytime you want to move Widget (where widget = project or folder etc) from $/something to another $/something use the Move tool. Checkin in the change and you should be good to go.
When you create a Working Folder within Team Foundation Server, you specify the server path you want to map, the local path on your computer, and the recursion level. For folders beneath those paths, the server determines the local paths based on those mappings (and recursion level) but it does not actually create any new mappings or any long-term state, the local paths will be recalculated. (In other words, there's nothing to clean up after a rename.)
If a folder rename is checked in on the server, to update this on your local workspace, you simply need to do a get on the parent folder. For example, if $/Foo is renamed to $/Bar, you should do a get on $/ in order to get that rename locally.
Nice and easy. Everytime you associate a file by checking it into TFS, TFS remembers the source path by creating a reference to it in the list folders mapped to your workspaces.
To clean this up, open Visual Studio, Connect to TFS. Go to File menu, chose Workspaces. You will see all the mappings that visual studio has managed to create for you. Feel free to clock or delete the ones you are not interested in. http://msdn.microsoft.com/en-us/library/ms181386.aspx
HTH.
Cheers, Tarun
Related
I'm switching to a new machine and would like to keep my TF files as they are. Thus I simply copied the entire folder to the new machine's (same as the previous one - C:\TF), mapped it to the TF server's root, and attempted to open a solution from the file explorer, hoping that it would bind more or less automatically.
I then ran into issues similar to others that have been described elsewhere, such as here and here. VS/TF insist that the binding on the solution and all projects is "invalid".
Unbinding and re-binding does not work, the binding reappears but remains invalid.
Recreating the workspace does not work.
There is nothing funny about the solution file's content.
The relative paths are correct - if I remove the bindings and try to add the files to source control, it overwrites the already existing files in the source control explorer (the item previously appearing as a grayed-out "Not Downloaded" becomes white with an "add" pending change).
Tried mapping the workspace to a "fake" network drive that pointed to the new machine's hard drive (just in case TF was mixing up the identical paths), still the same.
Deleting Team Foundation's AppData settings doesn't work.
When I perform a get on the solution folder, though, the binding becomes healthy all of a sudden. In the end I performed the get, deleted all the new files and put the ones from the old machine in their place. VS/TF apparently had no issues with the binding then. It's a rather inconvenient way of achieving that end, though.
I'm forced to conclude that TF doesn't want me to bind my own, local files to source control without first performing a get in that workspace, even if the file paths match what is on the server. Question: why is that? Am I doing something conceptually wrong? Doing it the wrong way? Is this behavior an idiot-proof feature of the tool, or just a limitation?
You're doing it wrong :/. | it's a feature, not a bug.
The workspace is registered on the VSTS/TFS server as well as in the local workspace cache. After moving the folders over to a new machine (and to the same folder location), you need to tell VSTS/TFS the new computer name these files now reside on.
You have to run tf vc workspaces /updateComputerName:oldComputerName workspacename to update the workspace registration on the server.
But I'm afraid you need to do this before overwriting the workspace with a new mapping.
Now I think the only option is to use the Unbind option, save all, then open the source control menu again and rebind all the projects in the solution. Or edit the solution files manually (there's a tool for it as well).
I am working with Team Foundation Server and I'm trying to fetch content from the server into my local folders.
so basically I'm using: tf get "companyName" /recursive /force /noprompt in the command prompt and everything is working smoothly and it gets stored under
C:\Users\myFolders\Escrow\XYZCompany\TFS
I'm using a program class and the path gets called from an app.config (XML) file into my visual studio class.
Is there a way to change the final path? I need to segregate the customers into subfolders so C:\Users\myFolders\Escrow\XYZCompany\TFS\CompanyOne or something similar, can this be done or altered? if I change the path I always get a message that everything is up to date and if I don't include the TFS folder, it gets created automatically whenever I run my command.
Thanks in advance for the help
This behavior is controlled by the workspaces you have mapped. A workspace represents the mapping between a location in source control and a folder on your PC.
It's not entirely clear whether your intent is to map the same source control location to multiple folders on your PC. You can't do that. In that case, it sounds like you need to adopt a branching strategy to allow for isolation of work between different customers.
No, you can't map the same repository to the subfolders of one folder. You could either:
Create multiple workspaces. Each customer has a workspace and map to different path.
Use branches. In general, you should map your entire team project to a single local folder under for example c:\Users\YourName\Source\Workspaces\, If you create branches for each customer, then you could map branches to c:\Users\YourName\Source\Workspaces\Main or c:\Users\YourName\Source\Workspaces\branch
Our TFS is not set up to be used in the traditional way since we moved it from Visual Source Safe which had a user\project hierarchy. Now I need to do a Move command to give another user a project that he is taking over from me and I want to use Move so it will preserve history. I understand that the parent of what you are moving must have mapping set up in order to get the option to Move activated and I've done that but it gives an error when attempting the move.
I hope the picture gives a better understanding. Help! Please!
Unfortunately, the 'Move' option will only move source files without their history information. TFS doesn't provide any feature to move items with history. You could use some other tools like TFS Integration tool.
Actually, when you use the 'Move' option to move, TFS first copy your files to your target place then delete the original files, so it looks like a migration.
That's why the history can't be seen after moving. The old history is still under the original place.
In addition, when you 'Move', the parent folder should be mapped and the target place folder should also be mapped.
I created a team project, say ProjectA
When I mapped it to my local folder, I found that the root server folder: ProjectA folder is not mapped. However the ProjectA folder within that IS mapped to the project. This is a problem as the BuildProcessTemplate is not included in source control and I cannot build my application.
How do I remove the mappings and start again?
On the source control explorer window in visual studio there is a drop down near the top for workspaces. When you originally mapped that folder, it created a workspace for you. If you want to change the mappings, it can be done by clicking the drop down and selecting the Workspaces... option. You can select your workspace and then click Edit.. to change mappings. You can also delete your current workspace and create a new one if you feel so inclined.
I have a number of SSIS packages spread throughout TFS, e.g. \Imports\impSSIS01\\, \OtherPackages\Exports\expSSIS02\\, etc. Anytime I open up any of those, I want the working directory to be E:\SSIS\, e.g. E:\SSIS\impSSIS01\\*.\*, E:\SSIS\expSSIS01\\*.\* When I try to set up my workspaces like that though, I get the error:
The path E:\SSIS is already mapped in workspace PC-MYCP01
I don't care if it's already mapped. I know it's already mapped. I want it to be already mapped. Just let me map it.
(Also, does this mean no one else on my team could use E:\SSIS\? I hope not, it's a shared drive we all need to use.)
Have you tried removing all your mappings and then map the root of your Tfs collection to e:\ssis. That way getting latest on a sub folder will extract the contents to a folder relative to e:\ssis.
Download the free Team Foundation Sidekicks 2010. It provides a convenient way to delete and modify workspaces.