You know, this is the kind of problem distributed VCSes can help you with.
For example, bzr lets you make 'local' commits without paying attention to the shared mainline, so you can keep working even if someone else has checked changes in.
Or if you go with a branch-per-developer, you merge the mainline whenever you want, and you also merge your branch *into* the mainline whevever you want.
That's interesting, and I will pass it onto my boss. Using a distributed VCS when there are four of us working in two offices next to each other *sounds* like overkill. 
You have to merge sometime, and having a build lock prevents you getting in a situation where you effectively have a "branch per developer", which is surely a chance for madness.
It's my bias as a bzr developer, but any time I see people adapting the way they work to a centralized VCS, I think: "here's something I don't have to put up with". Though Mutex is a very cute solution.
Distributed doesn't have to mean complicated. bzr is as distributed or as centralized as you want it to be. It's easy to get started with (3 commands!), and easy for people familiar with cvs or svn.
You do have to merge sometime, and with cvs, you do it every time you run "update". With the commit --local scenario, that's also how you merge. The difference with commit --local is that you don't have to update before you commit.
I know I sound like I'm selling something, but I'm very proud of what we've done with bzr.
Commenting by HaloScan
