TFS get command erroneously returns “All files are

问题:

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 changeset (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?

回答1:

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.

回答2:

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

回答3:

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.

回答4:

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.

回答5:

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

回答6:

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

回答7:

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.

回答8:

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).

回答9:

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"

回答10:

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.

回答11:

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

回答12:

Choose a date in future to get specific:

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