3

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.

kprobst
  • 16,165
  • 5
  • 32
  • 53
  • 1
    I'm not entirely sure I understand. Are you suggesting that TFS created new mappings for you implicitly after the rename or are you just trying to remove these two mappings? Can you share a screenshot of the workspace mappings dialog to help illustrate? – Edward Thomson Jun 29 '11 at 17:18
  • The folders were mapped 'naturally' say, project 'Widget' under D:\Home\Foo\Widget. That corresponded to $/Foo/Widget, because $/ was mapped to D:\home. Then they were moved to $/Bar, and TFS picked that up correctly, but I want them mapped 'naturally' again to D:\Home\Bar. IOW, I want to _remove_ the mapping, not re-map them. – kprobst Jun 29 '11 at 17:31
  • 1
    Sorry, I'm being dense - let's only talk about "mappings" as things that are literally workspace mappings that were created explicitly by you the user. (Team Foundation Server should never map a working folder for you.) I'm still unclear as to whether you have a single mapping for your $/ to D:\Home or if you explicitly created this mapping. The way you say you want to remove the mapping makes it sound as if you didn't create them... which means they never existed, which is why I'm confused. If you never created mappings, have you done a get latest at $/ to process the renames? – Edward Thomson Jun 29 '11 at 17:54
  • When you map a TFS folder to a specific physical path and then do a GET on a subfolder, TFS implicitly maps that folder to a physical subfolder of the parent. IOW, you don't have to map anything, TFS does it for you based on the fact that an ancestor folder is already mapped to something. That's the case here, except that when the subfolder was moved in TFS to another folder, TFS somehow kept the physical mapping to the old location. That's what I want to remove. – kprobst Jun 29 '11 at 18:08
  • 1
    Thanks for clarifying. The server isn't actually creating a mapping, it calculates whether the subfolders are contained within an explicit mapping based on the local/server paths and recursion level (full, one level, cloak, etc.) If your only mapping is $/ to D:\Home, and another user renames Foo to Bar, as soon as you do a get latest on $/, TFS should rename it for you locally. What does Source Control Explorer show if you navigate to $/Bar - it should show "Latest" as "True" and "Local Path" as "D:\Home\Bar", does it not? – Edward Thomson Jun 29 '11 at 18:19
  • Edward - holy bananas man, I never thought of doing a get latest on that project, TFS indeed sort of re-pointed the local mappings to the correct location. Thank you so much. Put a smiley or something on an answer down here so I can give you a big fat green checkmark please :) – kprobst Jun 29 '11 at 18:35
  • You bet - I fleshed out some of the details in the answer in case somebody else finds this helpful. – Edward Thomson Jun 29 '11 at 18:41

3 Answers3

2

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.

Mike Veigel
  • 3,795
  • 2
  • 20
  • 28
  • Thank you for your answer. Yes, this is pretty much what happens, except that I didn't think of simply doing a get latest on the parent root. It automagically re-pointed the mapping to the correct physical location. Talk about obscure :) – kprobst Jun 29 '11 at 18:52
  • Yep, gotta do a GL or refresh the view. – Mike Veigel Jun 29 '11 at 18:59
1

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.

Edward Thomson
  • 74,857
  • 14
  • 158
  • 187
  • This works but it may mean that you have to download 20 folders when you only want one. That is just insane. – David Sep 24 '15 at 14:41
  • @David I don't know what you mean. If you do a get on `$/`, you will only get the things that you have mapped. Nor will you get things that are up to date. – Edward Thomson Sep 24 '15 at 14:43
  • @EdwardThomson that wasn't a criticism - not of you anyway. I was just venting about TFS. I have $/Foo/Bar/Bletch -- but $/Foo/Bar contains many other projects which I don't need / don't know if I have space for / don't know if I want to wait to download. After remapping $/, the local mapping for $/Foo/Bar/Bletch still exists ... and seemingly the only alternative is to do a Get on $/Foo/Bar (and download those 20 other projects). – David Sep 24 '15 at 15:04
  • 1
    I guess I could have cloaked the projects I didn't want and then uncloaked them afterward. Still seems like a lot of unnecessary work. – David Sep 24 '15 at 15:05
  • I see - it's true, I was making assumptions about cloaking things that you didn't want so that a get on the root was effective. If you did have `$/` mapped (but you have not gotten everything) then in the above case you should be able to do a get latest of both `$/Bar` and `$/Foo`, but to be honest, I may be misremembering how TFVC handles that. – Edward Thomson Sep 24 '15 at 15:08
0

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

Tarun Arora
  • 4,692
  • 4
  • 30
  • 40
  • 1
    This works when the mappings are explicit, however in this case they showed up because the folders had moved and I had not done a get latest from the repo. They got 'fixed' when I did that, but they did not show up in the workspace edit screen because I never created them. – kprobst Jun 30 '11 at 21:40