catch up before checking in

I know it has been said many times before, and I know it’s just common sense, but after a little incident this morning I think it bears repeating: When you’re ready to check in your updates, be sure to catch up with the latest version before starting the check-in process.

We – my pair partner and I – were doing a little refactoring exercise at the end of a programming episode. We decided we had done enough for now, so we’d check in what we had and move onto the next card. So we fired up the SourceSafe (I know, I know) check-in process. It told us that someone else had changed one of our source files since we had checked out. That’s good: it prevented us trampling over someone else’s work. We went through the merge items and satisfied ourselves, by eye, that we had made the right choice in each case. SourceSafe then went ahead and committed the merged version to the integration stream. Wait a minute – that means we just checked in code that had never compiled, let alone passed any tests!

Fortunately, in this case no harm was done. Our merge-by-eye had worked. This time. But any decent CM tool should behave differently, in my opinion. Instead of merging and then checking in with cavalier disregard for the consequences, it should have simply aborted the check-in process when it noticed we were out of date. So now we’re forced to adopt a convention, a team policy that says

“merge from the integration stream into your workspace before every check-in, then re-build and re-test, and only then check in.”

I very much dislike the idea of having to rely on a policy for something like this. I find it very difficult to adopt new habits, and onerous to have a whole list of things to remember each time I carry out a task. And to ask a whole team, or department, to do the same is somewhat optimistic, to say the least. We need a CM tool that “stops the line” and forces us to catch up before we are allowed to proceed. This would follow the Toyota principle of jidoka or autonomation, effectively eliminating one source of manual error and rework.

(More on catching up before checking in can be found in the literature on team streams.)

Update, 21 jun 05
Subversion gets it right, of course.

Advertisements

2 thoughts on “catch up before checking in

  1. “merge from the integration stream into your workspace before every check-in, then re-build and re-test, and only then check in.”

    Before that final check-in shouldn’t you re-merge just to check nothing changed whilst you were doing your build and tests?

  2. You’re right, of course. I would like to assume that build-and-test is really quick, so that there’s little chance of someone else getting in ahead of us, but I know that’s just too optimistic. Maybe the team should have a check-in token (we’ve used a fluffy dinosaur in the past) – whoever has the token is in that final update-build-test phase and no-one else can interrupt it…?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s