Team Foundation vs. SourceSafe | Checking Out

When you check out a file in Visual SourceSafe:

  1. VSS Gets the latest database version of the file–or the pinned version, if it exists–to your working folder,

  2. VSS overwrites the working copy of the gotten* file if, as is usually the case, one already exists and is marked Read-only.

  3. VSS makes your working copy of the file writable.

When you check out a file in Team Foundation:

  1. Team Foundation makes your workspace version of the file writable.

Yesterday, I was sitting in a Team Foundation usability review in which somebody suggested that we should change CHECKOUT to EDIT in order to make it clear to users that in Team Foundation, to check out == to make writable and nothing more.

Is it too radical to suggest that CHECKOUT be replaced with EDIT? Nope. It’s user radicalism: a disciplined dedication to the obviation of customer pain in every design decision. I’m willing to bet that Jason Barile wouldn’t object to this change. Jason wasn’t present for this particular meeting but he routinely aliases h checkout with h edit.

The problem with changing checkout to edit is the same problem I faced this weekend after installing a new window in my kitchen. Where do you stop?** The kitchen walls need to be painted but you only need to paint around the new window. You can’t find an exact match for the paint color. You can’t “blend“ the texture to your family’s satisfaction. You definitely don’t want to move the refrigerator because you’re afraid of what you might find behind it, and if all that isn’t enough, your wife could go into labor at any second (!) and you’d have to leave the window untrimmed for months and months.  Where do you stop?

In the same way, I think that changing checkout to edit would lead us to reevaluate CHECKIN. Together, checkin and checkout are a dynamic and self-documenting duo. They are the cornerstones of a library metaphor that has helped countless users, including me, understand source control, albeit partially and incorrectly.

And that, my friends, is just it. The library metaphor is Broken with a capital ‘B’.

As a command verb, CHECKOUT infers that performing the operation on a file is like checking out a book from your local library. Unfortunately, the comparison is misleading.  In collaborative source control systems like Team Foundation and now Visual SourceSafe by default, multiple users can (to borrow from the library metaphor) check out, read, and make illegal annotations in the margins of the the SAME book at the SAME time. ‘But that’s impossible’, you say. Yup. CHECKOUT is the NOT self-documenting.

So if we supplant CHECKOUT with EDIT, what then becomes of CHECKIN? Finally, which comes first: the chicken or the checkout? 🙂

h edit korblogpost.txt
h submit korblogpost.txt

*In my opinion, GET is an ugly little dictator of a verb. It neither conjugates nor nominalizes with grace and I GET tired of writing around it in the source control documentation.  You wouldn’t believe the lengths to which I go to accomodate this innocuous looking verb. To be fair, GET is a good counterpart to the SET keyword. When used as a command verb however, I would much rather use retrieve. At the end of the day, my job is to make conventions, not break them.  But then, I never miss a chance to question authority.

Big Freaky Disclaimer   Microsoft Visual Studio 2005 Team Foundation is an orange tree and Microsoft Visual SourceSafe is an apple. They’re both sweet but they don’t compare. SourceSafe is a standalone source control system for individual developers and small teams. Team Foundation is an integrated work item tracking and source control system for professional development teams of any size. For more information, see The [new] Future of Visual SourceSafe and Microsoft’s New Source Code Control Application.

Comments (22)

  1. "p4 edit" and "p4 submit" are the commands that Perforce ( uses and it makes great sense to me.

    If it’s "checkout" and "checkin," you can bet that I’ll have my own aliases, too, to change that to "edit" and "submit."

  2. Edit and Submit makes sense and should work just fine. Is there further ripple?

  3. If you don’t get the latest version of a file when you check it out, when do you get it? Is it automatically updated when someone else checks in changes?

  4. David: there’s another command called "sync" (or at least that’s what it’s called in other systems) that synchronizes your copy of the source tree with the server.

    Edit then runs against a sync’d set of files.

  5. Nope. Nothing is done automatically. As a best practice, you should Get Latest Version often when working in a collaborative development environment.

    VSTF lets you work in your own little sandbox, or workspace, until you’re ready to check in your changes. Then…well, here’s what our command line specification has to say for the Checkin operation:

    "Changes are applied against the latest version of the files in the repository. If the user’s workspace files are not based on the latest versions, the checkin will fail and the user will be required to execute a "get" command to retrieve the latest versions. This is necessary to avoid conflicts on checkin. While we could prompt the user to resolve the conflicts on checkin, forcing them to do a get enforces the good practice of testing before checkin. If a file is checked out for editing, but does not differ from the latest version, a new version is not created and the change is silently removed from the changeset."

  6. Tommy,David,

    I would love to see "Synchronize" introduced as a flavor of or replacement for the Get command in Team Foundation. However, I doubt that it will happen. "Synchronize" is a two-way operation. Get Latest Version (GLV) a one-way operation. *Harmonize* is the most technically accurate, single-word alternative to the GLV command.

    Internally, I like to refer to GLV as DownSync. It pulls team changes down into my local workspace and synchronizes (or harmonizes) them in my little sandbox, merging resolvable differences automatically and prompting me to resolve all other conflicts manually.

  7. sync as used in systems like Perforce isn’t two-way, but it isn’t as simple as just getting the latest version, either. It’s possible to exclude files, versions, sync to a label, sync to the state of the source control system at a given changelist, date, etc.

    It’s still only changing the state of your local system, but it’s a lot more powerful than just getting the latest version.

  8. Honestly, every time I think more about it, the sd terms really do rock. I like sync instead of get (and Eclipse does as well! – Synchronize with CVS Repository), submit instead of checkin, edit instead of checkout.

    The worst I’ve heard from sync is that it’s unclear which direction the data flow is in. I almost buy that, but it’s really a red herring when you look at it in the context of a source control system. There’s no misunderstanding of how data flows *to* the repository – that’s submit! Therefore, sync is a data flow, yes, and it’s a flow *from* the repository. If submit didn’t exist or users didn’t know about it, then sync would be confusing. But, the reality check is that users *have* to know about submit (whatever it’s called) because they can’t do work without it, so knowing that’s pre-existing knowledge, sync is perfectly fine IMHO.

    In 1e6+ things it seems we keep realizing that the sd ways really make good sense, and their names for those operations (from p4, yes) make more and more sense to me on a daily basis 🙂

  9. Buck Hodges says:

    The Hatteras command line supports both edit and checkout today (they are aliases of each other). Also, submit is an alias for checkin. So, users can type whichever they prefer.

  10. Eyal says:

    How do you undo checkout in team foundation?

  11. Hank Fay says:

    As described, Team Foundation is dangerous.

    We don’t allow multiple checkouts in VSS (except for the pjm file created by VFP), using srcsafe.ini to make it happen right.

    So, when checking out, one is always working on the latest copy of the file. Yes, that enforces discipline (you have to IM the person who is using it if you need it); and that’s the point.

    TF sounds like it was designed to eliminate user complaints about not being able to edit a file; and will end up generating more, but different and more significant, user complaints.

    Thanks for this little series on the differences: it’s a big help (maybe it’s a big help in pushing us to Vault, but hey, that’s the purpose of information, right?)

  12. Eyal says:

    >> However, I doubt that it will happen. "Synchronize" is a two-way operation

    Here’s a crazy idea. Use the synch for both ways. As i understand, TF already knows the exact state of the file and can determine if it needs to be checked in, glv, or glv+merge before check-in. This way, i can have a single command that will make sure my local copy is synced with the server copy.

  13. Darcy Casselman says:

    This gets me wondering about SCC. SCC has pre-defined verbs that all providers *must* conform to, because the SCC provider doesn’t have a say in what shows up in the source control menu.

    It would be really nice if that were to change. Given that Microsoft is going to be providing two different source control tools with very different methodologies, I’d think it would have to, unless VSTS isn’t using SCC, which I suppose is not unlikely.

  14. Buck Hodges says:


    Forcing users to always get an exclusive lock on a file and edit the latest doesn’t scale. Also, it’s not dangerous. What happens when the user checks in is that the data tier checks to see whether the user has edited the latest version. If not, the user must merge his changes with the latest and then check in. If there are no conflicts, the user can merge automatically, rebuild the sources, and run the test suite to make sure everything is okay. If there are conflicts, they can be resolved using the graphical merge editor.

    This type of process is used widely by a number of commercial and open source version control systems. Microsoft’s internal version control system works this way too (there are thousands of developers using it).

    Before I came to work at Microsoft, I worked at companies that used VSS, Star Team, etc. They always used the exclusive checkout approach. There was always a problem with lock contention, and there were always problems getting a consistent copy of the sources because checkins are not atomic in VSS or Star Team.

    I invite you to try the Source Control in Team System when it becomes available in a Community Preview release in the next few months. I really think you’ll like it.


  15. Jason Barile says:

    You’re right Korby. I personally don’t mind the change to "edit". In fact, several of the Hatteras commands today support aliases. Beyond edit/checkout, you can use "move" as an alias for "rename". Heck… we even support "/?", "-?", and "help" 🙂

  16. Rossen Blagoev (MCS) says:

    Korby, regarding the Broken library metaphor, you should have a look at the SCC product Synergy CM from Telelogic. This is exactly what they do and they say it’s very innovative, easy, etc. They don’t have check out / check in, but exactly what you describe. First you say on which work item you will work, then the product tracks the changeset associated with the workitem as you modify files and at the end when you mark the work item as completed, the product checks in the whole changeset for you.

  17. VSS vs. Team Foundation Version Control | Checkout Behavior

    Team Foundation vs. SourceSafe | Cloaking…