Korby Parnell blogs that the checkin/checkout paradigm is broken here.

“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'.”

While I don’t believe the checkout/checkin model is broken, I do believe it is incredibly antiquated.  You can see the winds of change in development environments like Visual Studio where as a developer you can simply start working on a source file and it is automatically checked out for you.  So long and good riddance to checkout.

Assuming the model in the future is silent checkout, this leaves two operations up for grabs.  In my opinion, we should replace checkout and checkin with the following operations:

1)      Submit Change

2)      Checkpoint Change

The key thing a developer does when they are done is to follow some work submission process.  Typically the goal is to somehow get their changes into the team’s nightly build.  For most solutions today this is a multi-step and multi-tool process.  Checkin the changes, send some e-mail, resolve some bugs, update a plan, etc.  It would be G-R-E-A-T if integrated source code control and work item tracking would make this one unified gesture “Submit”.  The need to individually checkin files is in my opinion an edge condition.  Typically, I am checking in one change which is comprised of edits to multiple files.  In fact, forgetting to checkin one file from a set is probably on the top 10 list of reasons you broke the build.

The second operation perhaps is optional, but I think it is a needed and often overlooked feature that should be delivered by the source code control system.  Imagine my work has reached some stable point, but it is not yet done.  I’m about to try a radical change to an algorithm and I want a way back.  I want to keep a snapshot of the versions I have right now, but I don’t want it to go into the team’s nightly build.  Often, SCM tools or the way SCM tools are used require developers to work around the system like copy backup files locally.  That is because, if they checkin, the changes will be immediately exposed to the team even though they are not ready.

So out with checkout and checkin and in with submit and checkpoint.