Developer Drain Brain

November 23, 2009

Gated Checkins

Filed under: Development — Tags: , , , , — rcomian @ 2:21 pm

Back when I was working with subversion, I was at one point writing a hook script to check that a given commit was good. You know the kind of stuff: Have you added a comment, are you trying to change a tag, are you trying to hack the server, have you brushed your teeth, and so on.

It’s a fairly obvious thought when you’re in that environment to think … is this going to build? After all, here’s the perfect opportunity find out, and if it doesn’t we can just reject the commit and it’ll be as if it never happened – no-one else gets affected, nothing bad polluting the trunk, better chance of having a 1:1 workitem/changeset ratio, it’s all good.

It turns out that this idea is called gated checkin, and it’s available as a checkbox in TFS 2010. But despite my glowing report, I’m yet to be convinced of gated checkin as something that isn’t just a nuisance, compared with CI. I rejected it on the subversion side of things because our builds always took forever, and whilst a build was being checked, no-one else could commit. Not only that, but because I used a single repository for everything, it meant that no-one else could commit even if they were on a different project entirely. Thinking about this differently, this could be the best argument I’ve found for using individual repositories per project with subversion.

It’s much the same argument with TFS – the checkin is held open until the build and any other checks you use have completed, preventing anyone else from doing anything commit related. I mean they can’t even resolve any commit conflicts reliably, because they may or may not need to incorporate the changes that are being tested. This means your builds must be quick. This means they must be small. This means the projects must be small. Allegedly gated checkin becomes a requirement when you have >~60 people on a branch, as just by the laws of statistics, the branch is more often broken than healthy. Having 60 people on a single branch doesn’t sound small to me. If you’ve got 60 developers checking in every 2 hours, that’s a commit every 2 minutes. That’s your timeslot before your start impinging on developer productivity.

I’m not sure what the solution to this is. Apparently gated checkin is the solution to world hunger. Personally I prefer the idea of having less people on a single branch and merging more. Split the project into components and release them separately. Anything really. But I guess I’m going to have to try these before I can make a decision for sure. After all, they’re easy to setup and take out. If the builds are fast enough, they’ll certainly make the branch history cleaner, and surely that’s a good thing.


Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

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

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

Google+ photo

You are commenting using your Google+ 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 )

Connecting to %s

Create a free website or blog at

%d bloggers like this: