TFS get command erroneously returns "All files are up to date."

We are just in the process of migrating our TFS repo to Mercurial as we've had enough of TFS. Unfortunately TFS has thrown us one last curve ball before it lets us go. We've wrote a script that we intend to have "get" each c开发者_Go百科hangeset (including timestamp, check-in comment etc) and then add them to the Mercurial repo and check it in.

Unfortunately TFS is acting very strange when we execute the tf get * /version:C111 /overwrite command. It immediately returns "All files are up to date." But this is impossible. The workspace folder is empty! And viewing the details for the 111 changeset quite clearly shows that the changeset contains "stuff" i.e. the repo is certainly not empty.

What could be causing this?

---

TF will return "All files are up to date" if the itemspec you pass in is not found. If you don't include an absolute path, a relative path is assumed.

For example if you send

tf get myFile.cs /version:1009 /force

it looks in the current directory for myFile.cs, which doesn't exist, so it returns "All files are up to date." What we really want is

tf get C:\myproject\myFile.cs /version:1009 /force

Same thing with wildcards, eg

tf get D:\project\* /version:C111 /overwrite

Check out the itemspec link for more info.

---

You should try /all instead of /overwrite, this will force it to get all files, not just the ones it remembers getting to this workspace on the previous get.

MSDN Reference for Get

---

Instead of "Get latest version", you can "Get specific version" of type "Latest version" and check the "Overwrite all files even if the local version matches the specified version" checkbox. That will force a get latest.

---

I've had this same issue before, and after pulling my hair out, the only thing that corrected it for us was to un-map the workspace, delete all the local files, and then remap the workspace to disk - TFS would finally get a fresh copy of the files then.

We were using TFS 2005, for what it's worth - I'd be sad to hear that this situation still arises with newer versions. If you find another solution, please post it here, as I'd love to know how you resolved it.

---

I tried with /force, /recursive, /all options and still had the problem ("All files are up to date.") Eventually I realized the problem was due to mapping. So I deleted mapping and recreated.

My old mapping (incorrect) was done with a wildcard:

tf workfold $/* C:\DEV

So when I listed work folders (tf workspaces /format:detailed) it showed up like this:

Working folders:

  $//*: C:\DEV

When I remapped as below, the get command started working:

tf workfold $/ C:\DEV

and the mapping was showing like this:

Working folders:

  $/: C:\DEV

---

This can happen if you do not have adequate permissions to the source. I was able to see the entire source tree, all files, but I could not get the most recent version. I guess this is permission flexibility taken to the extreme (absurd?). To verify the issue was not workstation or mapping related, I tried looking at a code file on the team pages and received:

Image demonstrating lack of access to source file

---

I just had to fix this problem:

1. Get Tfs power tools. You can also get it from tools > Add-in manager inside visual studio.

2. It will require you to close visual studio to complete installation.

3. Once complete, open a command prompt in admin mode.

4. cd to your branch/solution directory.

5. run tfpt scorch (tfpt.exe comes with the power tools, if you don't see it, reinstall)

6. If it finds stuff missing, it will open up a dialog. Just hit next or ok and it will overwrite anything that does not match the server.

---

You can always add the "/force" parameter to TF GET to force it to get all files regardless of what it thinks you have in your local workspace (it maintains the versions of all of your workspace files on the server).

---

It looks like there are multiple ways to trigger this issue. In my case it was dealing with passing a relative path to a script that generated an absolute path and then passed that path to tf.exe. This is a Windows scripting problem more than anything else, but output from tf.exe is confusing.

Really what you'd like to see tfs return is "File not Found" instead of "All files are up to date".

In addition to the other suggestions made here, also double-check what you're passing to tf.exe by re-writing the command with echo first. If you're coming from a unix/linux background, string building just seems broken on win32.

broken.bat

SET PARAM1=%1
SET CMD_PATH="c:\path\to\%PARAM1%"
echo %CMD_PATH%

Result: broken.bat "tool.exe" => "c:\path\to\"tool.exe""

fixed.bat

SET PARAM1=%1
REM Strip quotes: http://www.dostips.com/DtTipsStringManipulation.php
for /f "useback tokens=*" %%x in ('%PARAM1%') do set PARAM1=%%~x
SET CMD_PATH="c:\path\to\%PARAM1%"
echo %CMD_PATH%

Result: fixed.bat "tool.exe" => "c:\path\to\tool.exe"

---

Check your workspace. I went to delete it as above (which probably would have fixed it as well) but I noticed that someone a project within my project got it's own workspace assigned in addition to the overall workspace. I removed that project from the workspace and it downloaded all my files when I clicked ok to exit the workspace menu.

---

My problem was that I was running VS developer command prompt from VS 2012 studio but my workspace mapping is inside vs 2013.

Make sure you run tf.exe from inside of visual studio directory which has workspace mapping, than simple tf.exe get "path" /all /recursive works just fine

---

Choose a date in future to get specific:

tf get * /version:D01/01/2099 /recursive /force  /noprompt

---

Also make sure you have rights on the team project site in your project collections.

In my case, I could see the project folder and branches in TFS source control explorer, but I couldn't access the project's TFS website.

Instead of returning an error detailing a permissions issue, VS instead said all files are up to date when I tried to get the latest version.