Lost at least one changeset in TFS - Now won't check in changes to file involved, what to do?

We've lost at least one changeset in TFS (we don't know yet if there's more, could be none). We noticed a changeset that was at the top of the list is now gone. We think there might be two at least because the symptoms below also exists for at least one other file we've discovered. Additionally, we can see a hole in the changeset numbering sequence, and we don't believe the changeset with the file described below is that one.

The single file involved had one line changed, and the version in TFS has the file before the change.

Doing a get latest or get specific version gives me the old file, before the change.

After doing the "Get specific version", in Source Explorer, in the column that shows workspace status, it says "No" indicating that the file is outdated. Nothing I've tried so far gives me the file with the change that was checked in.

If I try to view the file from the Source Explorer, it says my file is out of date and asks if I want to view the server version or the workspace version. Selecting the workspace version gives me the file before the change (probably because I did the get specific version above), selecting the server version gives me nothing, dialog just goes away.

If I check out the file, and redo the change, and try to check in, it says that a newer version exists on the server and asks me how to resolve. I can pick discard local changes or discard server changes. Since I want to check in my changes, I select to discard the server changes, but when I try to check in again (conflicts in TFS stops the checkin process), it just repeats the conflict and asks what to do.

Basically:

• Changeset is gone, verified with the developer that checked it in
• File does not have the change on the server
• Server is confused regarding version of this file, complains about outdated version if I try to 开发者_如何学Pythonview it
• Won't let me check in changes, just repeats a conflict with a newer version, presumably the file the developer checked in that for some reason is no longer available through a changeset

So... anyone had this problem? This is TFS 2008 with everything I know of updates applied, including all service packs on the developer machines, running Visual Studio 2008 Professional with Team Explorer 2008.

What do I do? Is my only recourse reverting to the nightly backup?

Edit: Things I'm trying after posting the question:

• Checking disk space on server hosting the SQL Server (same as the TFS server): Plenty, 6GB free on one disk and 9GB free on another. Perhaps not plenty enough for the future, but easy to increase (virtual machines), but should not have anything to do with our current problem.
• No change: Recreating a fresh workspace in a different folder on disk (I deleted them all before adding a new one), doing a "Get specific" version on root folder of project and checking the bottom two checkboxes (overwrite writeable and overwrite all), afterwards says that I have the latest file (Yes in that column I mentioned above). Viewing the file shows me file before the change. Doing a "Get specific" version on that particular file makes it turn to "No", same problem with checkin.

Solved??

I did another checkin on a totally different file, not including the file we had trouble with above, but that file was "attached" to that changeset, even though it was definitely not checked in by me when I tried this.

In other words, it looks like the part of the changeset that related to the file was still in TFS, with the right changeset id, so when another changeset appeared with the same id, that file became a part of it.

Has anyone experienced anything like this? It doesn't really improve my trust towards TFS if things like this can happen.

We still have another file that misbehaves, I will have to see if it has all of the same problems or not and what, if anything, we can do with that. If that file is related to the other changeset we seem to be missing, I don't think we can get that changeset into the database unless we fire up a SQL tool (which I'm really not going to do.)