> TFVC is a centralized-server model that requires constant and active communication between a client (read: developer) machine and the server. If, for example, the network goes down for 1 hour, development grinds to a halt. The reason here is that TFS will mark all files as read-only on the filesystem until you have asked the server to check them out for you.

Perforce works the same way, causing much frustration for me whenever I have to work with a slow and unreliable p4 server (and, despite Perforce marketing, those exist). You can override p4 and make writable the files you want to edit without telling the server. But when you want to check in a changeset, you have to tell the server you edited the files, otherwise they will get left out of the changeset. Worse yet, if you try to get too clever with your local copy's settings, the p4 utility might overwrite your changes with a newly checked-in version the next time you update your local copy.

When I worked at Microsoft in the early part of the last decade, we used a Perforce fork called Source Depot. (Internet mentions of sd are rare, but here is one: http://stackoverflow.com/questions/491295). I have no experience with TFS version control, but it looks to have taken a lot of inspiration from sd, which was a fresh breath after the previous revision control tool which didn't even support branches.