I'm using Visual Studio 2012 and TFS Express. I have the top level collection 192.168.100.100\Collection; under it I have a project for each program; under those I have the solution folders. So in the project folder FooBarBaz I have the solution OldName. (I'd rather not post screen shots of the folder tree, but I can rig up an ASCII art depiction if needed.)
I want to rename the folder OldName to NewName. I have already successfully renamed the solution itself and checked that in. I have also successfully changed my local mapping from ~/Projects/OldName to ~/Projects/NewName.
In MSVS Source Code Explorer, when I right-click on OldName the context menu options Rename and Move are both greyed out.
How do I rename the folder in TFS? I am the team's TFS admin so I can use the web-based settings and I can also use the TFS control panel on the host system.
Right click on the folder name in the left panel.
Also, you must have those folders mapped into your current workspace.
Pre-step assumption: Create local folder with solution and project under it and added solution to TFS. TFS now has a path in TFS pointing to a TFS folder that contains your added solution. This location is bound to the location on your local machine that is likely out of sync with the path structure represented in Source Control Explorer.
You want to rename the folder in TFS that holds your solution. When I right-click in Source Control Explorer, “Rename” is grayed out. It appears that TFS wants the TFS path to match your local path structure.
In order to rename the TFS folder I had to:
Check everything in
Remove binding to source control
Do a get latest - TFS assumes structure inherited binding - so whatever the folder is named and where it is in the TFS path structure, the get latest will create a local folder to hold the code.
Now, right click on the folder and do a rename in Source Control Explorer.
TFS and your local workspace are now in sync. If you now go and rename the TFS folder that contains your solution, the next time you open the solution, your local folder name will be automatically changed to match TFS.
Of course, don’t forget to go back later - after VS has released the lock, and delete your old/first/”no longer bound to TFS” version of the local solution folder.
I hope this helps someone else.
Related
I'm using VS 2013 with TFS online. I have several branches and workspace.
When I open a solution, I cannot easily tell which branch and which workspace I'm in easily.
In old vs source safe, I can tell by Source control BIND. The current open solution is bound to a branch and workspace. Where can I get the info properly? Source Control Explorer, Team Explorer seems not good enough.
After research, I confirm that VS does not tell which branch you are working on.
You can do as timB33 does. But, this does not tell you that you are in which branch.
Team Explorer and Source Control Explorer shows identical for both solutions from different branches.
For sure, I do open folder by "Open Folder in File Explorer" on a project or solution. The folder path that I always setup with proper branch structure tells me 100% where I am.
I wish VS improve to display the current folder path or TFS path of 'Source Control Explorer' for the current project or solution on Title or Property or Team Explorer.
I organise my workspaces like this:
C:_ws\tfs\collnZZ\dev\dev04
C:_ws\tfs\collnZZ\fb\fb01
C:_ws\tfs\collnZZ\main\main31
I also keep an eye on >TeamExplorer>SourceControlExplorer and then I look at Workspace and expect my local path (beneath workspace) to be mapped.
I created a new project in my solution under a newly created folder. Not just a solution folder. It is placed under a physical folder also.
Say, my original solution is like this:
MySolution
- MySolution.Web
- MySolution.Domain
Now the structure is:
MySolution
- App
- MySolution.Web
- Lib
- MySolution.Domain
- MySolution.Repositories
- MySolution.WorkerServices
- Test
- MySolution.Specs
- MySolution.Unit
Please note in addition to the newly added projects, MySolution.Web and MySolution.Domain are moved to a physical subfolder also.
To move MySolution.Web into the App folder, I moved the files outside Visual Studio and then edit the MySolution.sln manually with a text editor so that the project entry can point to the correct physical location.
Since those two projects are almost empty, I don't really care about losing history.
Then I find I could not check in the change to TFS!
I got Team Foundation Error, saying Could not find a part of the path.
As suggested by comments/answers to this question, I have done an Add Items to Folder in my Source Control Explorer. Now the new folders and projects have a plus sign ahead of their icons. But the MySolution.Web and MySolution.Domain still stubbornly exists in the root. If I try to delete them, it says One or more children have pending changes. It appears TFS tracking failed to understand what I am doing and pending changes are related to those projects even though they are not in existence physically on my local computer.
How can I fix it? What is the correct way to add a project into another folder?
It sounds like you need to add these new folders to source control.
In Source Control Explorer, use the tree view and right-click on the folder above the folders you want to add. You should see an "Add Items to Folder" menu item. Click that, and follow the instructions.
Note that all involved folders must be mapped into your workspace in order for this to work.
After using a "GetLatestVersion" to retreive my coworker's new project added to Source Control, we realized that the folder structure was incorrect. He deleted the issues on Source Control and everything looked great there. It runs on his end.
Unfortunately for me, even after running the "GetSpecificVersion" and checking all the overwrite boxes, I cannot get the new version of his project on my local workspace.
Ok.
How now do I delete the project on my end without TFS knowing (so I don't have toCheckInanything and TFS doesn't think it needs to bring anything onto the server from my local workspace).
It makes most sense to me to:
- log out of Source Control, close the project and Visual Studio,
- go into my workspace folder and delete the coworker's broken project
- log back into Source Control, bring up the workspace project in Solution Explorer, and re- "GetLatestVersion" and overwrite files.
Has anyone had this problem before? I'm working in VisualStudio 2012
Are you 100% positive that your co-worker did in fact check in all of his changes that "fixed" it? I would start by double checking that. In team explorer, make certain that they do not have any files that need to be checked in under "Excluded Files".
If you have a TFS Build Server, make certain that the CI build (or you can manually run it) was successful. This will at least prove whether TFS has the project buildng correctly.
If you don't have a TFS build server, have another co-worker pull it down to verify that everything got checked in correctly.
If you are sure that they checked in everything ok and it is still not working for you, try pulling it down to a different directory. Also, you can manually delete your copy of the solution through file explorer and then pull it down again (with the overwrite checked).
I'm trying to use TFS but there is one problem:
I created project called NewWeb and added him to source control, after that I deleted this project and mapped Global to another project on cloud but one folder from still shown in the tree under the deleted project.
NewWeb is a separate Team Project, so has nothing to do with MVC4. You cannot map two source control folders to the same folder on your hard drive, so you can't have one folder shared by two team projects.
Instead, you will need the global stuff to be held in one place in source control and then referenced from there by your code solutions. Either use a separate Team Project for globals and each application, or have one Team Project for all your code, and place each app in its own subfolder.
finally, I'd advise that you try to minimise the mappings, I.e. map $/ to your hard drive so your workspace matches the source control layout. Using mappings to move things about Introduces complexity that leads to problems.
Try deleting $tf (hidden) folder from your project folder.
To avoid conflicts use tfs destroy command to destroy all the folders.
Goto File -> Source control -> Advenced -> Workspaces, in the popup click edit and remap the folder where there should be.
Check in pending changes.
I am trying to use TFS storing non-VisualStudio source code. Working with Visual Studio 2012 and Microsoft's online Team Foundation Service.
I've setup a TeamProject and mapped its root to a local folder. All it contains at the moment is a BuildProcessTemplates folder in it. (which was created as part of the TeamProject)
I copied my source code externally (using windows explorer) into the TeamProject root folder on my hard drive and since my TFS workspace is NOT a server workspace but rather a local workspace, I was expecting VS to detect the folders/files and show them in Pending Changes window .... yet it doesn't.
Interestingly, new files in the root folder are detected as "Excluded Changes" but new folders are not detected.
What am I missing?
First make sure the newly added folders contains files.
Are there any Detected changes shown in the Excluded Changes section?
Pending Changes > Detected changes link > The Promote Candidate Changes dialog box appears > check the files you want and click Promote.
I can't say I have ever noticed nor expected TFS to automatically pick up files or folders added to a mapped directory as pending changes.
I always just add them manually using the 'Add existing items' option from the source control view.
It may actually do (or at least be meant to do) the auto-detection, but I can't say I've ever relied on it. I don't think it's something to fret too much about - adding them manually is easy enough, and the 'Add existing items' option is usually smart enough to show you which files are not already under source control, so even if you need to add even more files later, it shouldn't be too much extra effort.