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.