My problem has been solved, although not 100% understood.
The problem seemed to be with the NIC advanced setting TCP_LargeSend. After disabling this option the mismatched checksum issue went away.
Here is the ad nauseam description, in case you care. I know you don’t really care but I will feel better for having told someone about all the hard work I put into understanding the problem.
I started by using ethereal (on advice from email response from dev@subversion.tigris.org thanks Molle B.) and found checksum errors on all packets being sent. I updated my NIC card driver (Gigabit RealTek RTL8169/8110) it did not help. While I was flipping through the various tabs on the NIC properties I stumbled across the Advanced Settings and I found an interesting option called offload Checksum. On a web search I found the Windows article “Windows Network Task Offload” http://www.microsoft.com/whdc/device/network/taskoffload.mspx.
I tried disabling the offload Checksum option and the TCP checksum errors in ethereal went away but the subversion checksum mismatch didn’t. In the Windows article they mentioned the TCP LargeSend option also. I got to thinking, Subversion fails with large files and the NIC card has a LargeSend options. Hummmm, very curious! Reading the windows article explained what might be happening. The NIC card is getting a large block of data, bigger that the MTU and trying to split it up by reusing the header for the large block. For some reason the receiving end of the TCP message is not putting them back together correctly. Turning off this option in my NIC card fixed the subversion checksum mismatch problem.
Side note about the TCP checksum errors in ethereal:
The TCP checksum errors, as best as I can understand , are because the NIC card is setup to do the real checksum. This means that ethereal is not seeing the finial checksum after the packet is sent. If I disable the offload checksum option on the NIC the TCP checksums in ethereal are correct. Reading the Microsoft article explains why this may be happening and why you should keep it enabled (30% reduction in CPU usage). Bottom line is it was not causing the problem but was just interesting none the less.
Yet another quirk in the gazillion PC configurations on the planet!