> 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.
Editing of local files "behind the back" of the P4 server is not that bad. When you reconnect to the server, just ask your P4 client to "synchronize offline changes" (in P4V, I think) or just checkout your entire clientspec and ask your P4 client to revert unchanged files. I'm sure these operations could be easily scripted, too.
Clearly not ideal, but workable. I'm surprised Perforce has not created offline changelists (like git or Mercurial's Patch Queue). The feature could probably be implemented entirely in P4 client code. Perforce has implement server-assisted "shelving" of changelists, but I don't find that as helpful as local branches or changelists would be.
> When you reconnect to the server, just ask your P4 client to "synchronize offline changes" (in P4V, I think)... I'm sure these operations could be easily scripted, too.
p4v does have a lot of added features and conveniences. Maybe I'm an old fart, or maybe I'm just too used to sd (which didn't have an official GUI client app when I used it) but I don't actually like to use p4v, preferring to use the p4 command-line tool. So, yes, I've gotten used to automating certain operations via shell scripts that wrap p4.
> ... or just checkout your entire clientspec and ask your P4 client to revert unchanged files...
If you do that, though, the server will tell everyone else that checks out any file that you have it opened for edit too. This can be really misleading when they want to delete or integrate to the file. I don't like that Perforce implicitly discourages merging branches through "who else has opened this file" notifications, but that's how it is and I'd rather not abuse the system.
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.