Brian A White's Blog : Software Configuration Management

SourceGear Building Heterogenous Client for Team Foundation

brianwh — Thu, 13 Jan 2005 00:58:00 GMT

For all you out there wondering how you are going to support your Unix, Linix, MAC, and yes Eclipse developers if you move to Team Foundation take a gander at Eric Sink's Blog http://software.ericsink.com/entries/allerton.html

Project Management, Version Control, Work Item Tracking Presentations

brianwh — Mon, 15 Nov 2004 19:06:00 GMT

Last week I presented at Visual Studio Connections in rainy Las Vegas (Yes, rainy. Sadly, yet not surprising I can also report moderate losses). Several of you asked me for copies of these presentations and thanks to the help of Rob Caron you'll find the presentations (below) downloadable here.

VMS352 - Visual Studio 2005 Team System: Software Project Management
In this session you will learn how to take advantage of the combined power of Visual Studio, the Microsoft Office System, and industry proven practices to successfully manage software projects—from conception to deployment.

VMS355 - Visual Studio 2005 Team System: Enterprise Class Source Control & Work Item Tracking
This session introduces the new Team Foundation Server in Visual Studio 2005, including the new Source Code Control, Work Item Tracking and Team Portal. See how an integrated and extensible server-based system will boost your team’s productivity by significantly streamlining your development processes.

The Checkout/Checkin Model is Antiquated with a capital "A"

brianwh — Fri, 30 Jul 2004 22:44:00 GMT

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.