Team Foundation vs. SourceSafe | Checking Out
When you check out a file in Visual SourceSafe:
- VSS Gets the latest database version of the file--or the pinned version, if it exists--to your working folder,
- VSS overwrites the working copy of the gotten* file if, as is usually the case, one already exists and is marked Read-only.
- VSS makes your working copy of the file writable.
When you check out a file in Team Foundation:
- 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
- Anonymous
July 28, 2004
"p4 edit" and "p4 submit" are the commands that Perforce (www.perforce.com) 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." - Anonymous
July 28, 2004
Edit and Submit makes sense and should work just fine. Is there further ripple? - Anonymous
July 28, 2004
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? - Anonymous
July 28, 2004
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. - Anonymous
July 28, 2004
The comment has been removed - Anonymous
July 28, 2004
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. - Anonymous
July 28, 2004
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. - Anonymous
July 28, 2004
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 :) - Anonymous
July 28, 2004
The comment has been removed - Anonymous
July 28, 2004
How do you undo checkout in team foundation? - Anonymous
July 28, 2004
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?) - Anonymous
July 29, 2004
The comment has been removed - Anonymous
July 30, 2004
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. - Anonymous
July 31, 2004
Hank,
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.
Buck - Anonymous
August 01, 2004
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" :) - Anonymous
August 03, 2004
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. - Anonymous
February 16, 2006
VSS vs. Team Foundation Version Control | Checkout Behavior
Team Foundation vs. SourceSafe | Cloaking...