Various people have hit some variation of the following:

"When I checked out a file, I got a message saying there was a newer version in source control. But, when I ran resolve, it said there were no conflicts to resolve. What gives?"

There are at least three possible reasons for this, I'll address them in order of most- to least-likely.

1. You got a warning, but you didn't actually create a conflict yet. This is a more interesting version of the basic "you don't actually have any conflicts" scenario below, and is by far the most common cause of an unexpectedly empty resolve dialog.
   Our resolve command only handles conflicts that have already been generated by other commands - usually get or checkin, but merge as well. So, while we try to warn you if you're heading for a conflict, that warning doesn't actually create the conflict; you could see the warning, undo your checkout before making changes, and do a get latest, or you may have good reasons for pending your changes against an older version - we're not going to make a hasty assumption.
   If you do want to go ahead and generate a conflict so you can merge/auto-merge your changes, just go ahead and try to check in, or do a get. The good news is that we'll go ahead and bring up the resolve dialog when you create any conflicts (unless you specified /noprompt from the command line).
2. You don't actually have any conflicts. This might sound like a joke. But, there are several warnings/errors we issue that might sound like something you could address with resolve, but are not actually conflicts. The example that comes to mind is "Unable to delete <folder> because it is not empty." This is actually "just" a warning - we won't move/delete that folder because there are items under it which we are unable or unwilling to delete - unversioned items, or items in use by a process, etc. We'll mark the folder and any versioned contents as deleted/moved anyway (from the server's perspective), but it's up to you to go do any final cleanup (if necessary).
3. You ran resolve from the wrong workspace. This can happen in VS and from the command line. In VS, remember that whatever UI component has focus when you run File/Source Control/Resume Conflict Resolution determines the workspace for which we'll run resolve. This might be the pending changes tool window, the Source Control Explorer, or Solution Explorer - each of which has an 'active' workspace, and each of which may be different (why they're all potentially different is the topic for a whole different blog, let alone a blog post). Note: If Team Explorer has focus, you won't have the menu option.

To summarize parts of 1&3: TFS Version Control can issue warnings, errors, and conflicts. Resolve will only address conflicts, you must decide how to handle errors, and warnings may or may not require action. Makes us sound more like a compiler than a source control server, doesn't it?

In v1, there's no obvious way to distinguish between conflicts, warnings, and errors. They're in the same color in command line output. We generally return an exit code of 100 if there were any errors, and 1 if there were any warnings or conflicts, but that's not much help if you're using VS. I don't think it will bother most people; in general, if you do something that causes a conflict, you'll also get a resolve dialog at the end of the operation, and you'll be able to resolve the conflicts and move on.

That's all for now.

Alive in the superunknown...