I have Visual Studio 2012 and when I'm trying to get last version it doesn't work and it says that it's says that "All files are up to date". It is because I deleted file locally after I got it from TFS and I guess in Visual Studios memory it's written that there were no changes from that time I got it and now it doesn't let me download it although I don't have it.
How to "tell" VS that my local folder is changed?
P.S. I guess it can be also done with "Get specific version" but that option doesn't appear to me when i right-click on file I want to get from server.
EDIT:
I found that my workspace changed automatically (or rather with me not being concentrated while making new project), so VS was actually checking other directory all the time. For all those who might have the same problem - check your local path and if you see that it's not good, change it.
Here is how you can change it:
http://social.msdn.microsoft.com/Forums/en-US/tfsversioncontrol/thread/d0c6982f-4f5e-4b1c-830b-3af9fb127922/
You are right, TFS saves what version he gaves you and changing/deleting it without to notify TFS, you won't get anything. The "Get Specific Version ..." is what you need. Therefore rightclick on the item you want, in context menu choose "Advanced --> Get Specific Version". Check the second option to "Overwrite all files even if the local version matches the specified version".
Not saying this is a solution, but I had similar issues after remapping one of my projects. Ultimately what I did was delete my local Solution File (.sln) and re-opened the project via the Project File (.vbproj). After that I was able to see all of my latest file versions that appeared to not be down loading. Once you click save on anything it will re-prompt you to save a new solution file.
i don't know if this is specifically what the OP was trying to accomplish, but here's my story: my machine crashed, had to get it reimaged; once VS2015 was installed, i went to source control explorer, right clicked the branch i needed >> Advanced >> Get Specific Version, checked the "Overwrite..." boxes, clicked "Get" and got the "All files up to date..." message. buster. obviously the code was NOT up to date.
fast forward: i fixed this issue by deleting my workspace's pertinent mapping to code base i needed, saved it, and re-added it.
hope this saves some headaches.
You'll want to Get Specific Version and to check the box to enable overwriting of existing files. That will ensure you're actually up to date.
You can also switch from a server worspace to the new local workspace which should also help solve issues like this.
Related
I accidentally deleted a wrong file in Visual Studio 2019 before commiting the changes. I lost not a lot of work but I want to prevent this in future.
Can I setup VS 2019 somehow that files are not immediately deleted but kept in a cache for a while?
Supposedly there is already a backup folder which VS uses for deleted files, but this folder was empty in my case. And also the fact that VS moves files into the Windows bin doesn't help me because my repository is not on the system drive.
Do you know about any settings in VS or is there maybe an extension?
Not exactly what you are looking for but this extension could help you. It migth not prevent the deletion, but give you the opportunity to recover the code.
I haven`t tested it and I am also not sure if it will work with VS2019.
A visual source code plugin for maintaining local history of files.
Every time you modify a file, a copy of the old contents is kept in the local history. At any time, you can compare a file with any older version from the history. It can help you out when you change or delete a file by accident. The history can also help you out when your workspace has a catastrophic problem. Each file revision is stored in a separate file inside the .history folder of your workspace directory (you can also configure another location, see local-history.path).
https://marketplace.visualstudio.com/items?itemName=xyz.local-history
The answer here is to use a version control system (like git) and keep a full history of your project.
Even on simple personal projects it is worth doing.
On my VS2012 I noticed that if i edit a file that is not checked out in a notepad and save it, in TFs it will be marked as checked out and edited. So far we haven't found too much of a problem of it, but potentially people can get careless and make/save changes unintended.
Is there anyway to turn off that feature?
What you're seeing is now default behavior for Local Workspaces. One way to 'undo' this is to set your workspace to a server workspace once more. But I suggest you first investigate the benefits of local workspaces before deciding to turn it off. People still have to check in files, so there is a gate between changing the file and actually committing them to source control.
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 get the error "The device is not ready" when I open visual studio, and also when I try to interact with TFS (check in, get latest, etc.)
I have tried the following to correct the issue with no luck in resolving it:
Reboot
Repair Visual Studio
Uninstall/Reinstall Visual Studio
What device is not ready? How can I make it ready or otherwise correct this error? I'd prefer to not reinstall my OS, but I will if I need to.
This is (mostly) caused when the location your workspace is pointed to is no longer available.
All you need to do is reset the workspace
(
open sourcecontrol,
in the toolbar click on the dropdownlist workspaces,
edit the workspace of the computer the drive changed
set the local folder to the correct location
)
I think this sort of thing can be caused by a no-longer-accessible drive. Here's something to try: Clear out your Most Recently Used project and file lists:
Run regedit.
Navigate to HKCU\Software\Microsoft\VisualStudio\11.0\ProjectMRUList.
Delete all the "File" items (File1, File2, File3, etc.).
Navigate to HKCU\Software\Microsoft\VisualStudio\11.0\FileMRUList.
Delete all the "File" items (File1, File2, File3, etc.).
If that doesn't work, have a look through the other items in 11.0 and under it, looking for no-longer-valid directories. Here are some other nodes to look under:
11.0
11.0\External Tools
Find (might have a directory specified for find-in-files)
JavaScriptLanguageService
Keyboard
NewProjectDialog and subnodes
...and there are probably several others, but at this point I got bored with looking. Anyway, look through the various nodes for a network location or removable drive that doesn't exist anymore, and get rid of that path or point that path elsewhere, and see if the problem goes away.
I recently had a HDD fail, which I managed to repair. In doing so, the drive letter changed. I changed the letter of the drive back to its original letter designation, and this issue no longer occurs.
I just had the same problem. I had clicked the button that was asking me to upgrade to a local workspace. After I did that I was getting the 'device not ready error' anytime I tried to do anything with TFS. The response marked as an answer did not help me. I had to completely remove the workspace (via the menu described in Olivier's answer) and then re-add a new workspace.
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.