Q1 : Does TFS gaurentee it's storage?
For instance, if I commit a file with content
printfn "%s" "fizz buzz"
will I get back a file with content
printfn "%s" "fizz buzz"
or will I get back file with content
printfn "%s" "fizz bUzz"
and an error or a way of identifying the content checked out was incorrect.
Git uses SHA-1 to do this kind of thing.
Q2 : What happens on a git checkout when the content of file in the .git store becomes corrupted, and it's sha pointer is now 'incorrect'? I have never tried, but what would happen at the git command line when the bits on the disk of a git repo get corrupted?
Q3 : Similarly, what would happen on a TFS checkout when the content of files in the TFS database become corrupted?
TFS uses MD5 for its checksum. When you upload a file as part of a changeset or shelveset, you also send the MD5 that you calculated. The server will also calculate the MD5 of your upload contents to validate that there was no corruption on the wire. Similarly, when you perform a Get from the server, it will deliver the MD5 of the content and clients will validate that the checksum matches.
As to your question about corruption, I can only speak hypothetically and only from having worked on TFS. Obviously if your database is corrupt, all bets are off and we make no guarantees as to anything.
When you say "a TFS checkout" (after having discussed "a git checkout" above it), I assume you mean "a TFS working folder mapping". The only problem should be when you try to do a get of the corrupted file. For example, if you had a corrupt $/Foo.cs at changeset 42 and you did a get of changeset 42, then it would fail. Your local version would not be updated on-disk or on the server and you would not be at version 42 locally.
If, however, there existed a $/Foo.cs at version 43 and it was not corrupt, then you should be able to get changeset 43 without problems. The server would not examine that previous version.
If you had gotten $/Foo.cs at changeset 42 before the database became corrupt, you should be able to check the file out (in the TFS terminology of "checkout", meaning to pend an edit), make changes, then check the file in, but there's certainly no guarantee of this. You would need to make changes, since if a client tries to produce a changeset or shelveset that includes a file with the MD5 of the current shelveset, the server will instruct the client not to bother sending the changes.
Again, this is all fairly hypothetical. We didn't exhaustively test data corruption scenarios. Realistically, if your database is corrupt, all bets are off and you should restore from a backup.