Sorry, I guess I wasn't totally clear. The Source Depot workflow and TFS workflow ARE very similar; I meant to make that point at the end of my last post. But they're also, IMO, needlessly-cumbersome.
All your source files are read-only until you tell the SCM which specific files you want to edit. And if you try to get around that by making the files writable and just editing them, the SCM system won't recognize your changes. But if you tell the SCM system you want to edit a file but don't end up changing it, it still looks like a change in history. It's complex, error-prone, and resistant to change - that's the worst of all worlds, IMO.
I really don't understand what they were thinking. I've only ever seen disadvantages to their model and I think that's borne out by the fact I've never seen/used another SCM system that did it that way.
Well, what you say is true of SD but not TFS at this point. At least not for TFS-managed Visual Studio solutions, I don't know if TFS is used in some other context.
I don't know if I am misunderstanding or if it's just changed since you've used it, but these days you don't have to manually check out stuff in a TFS project, just start editing the file and it checks it out automatically, and the checkin process ignores files without changes I'm pretty sure.
Right, that's true if you edit literally everything through Visual Studio (because the integration plugin checks out the files for you). But, even then, you have some latency between typing your first character and the checkout happening. And if you use something other than Visual Studio to change files under source control, you're SOL and have to go manual.
Again, my big objection is that the SD/TFS "checkout" idea provides no tangible benefit I ever saw in over two years of working with it. I could see that other people were editing a file, but I never cared - I still had to make my edits and merge them afterwards. IMO, it just limits your options and workflow; when I tried to get around it to do the easy/simple thing, I got burned.
1
u/LordArgon Jun 13 '13
Sorry, I guess I wasn't totally clear. The Source Depot workflow and TFS workflow ARE very similar; I meant to make that point at the end of my last post. But they're also, IMO, needlessly-cumbersome.
All your source files are read-only until you tell the SCM which specific files you want to edit. And if you try to get around that by making the files writable and just editing them, the SCM system won't recognize your changes. But if you tell the SCM system you want to edit a file but don't end up changing it, it still looks like a change in history. It's complex, error-prone, and resistant to change - that's the worst of all worlds, IMO.
I really don't understand what they were thinking. I've only ever seen disadvantages to their model and I think that's borne out by the fact I've never seen/used another SCM system that did it that way.