This is really interesting and I would love to know what the code in question was responsible for.

Requiring that work on it be done single-threaded like this suggests that some other part of the overall process broke down somewhere - the developers/automated tests/continuous integration server couldn't catch merge conflicts? Code reviews weren't done and made visible to everyone else on changes to this special code?

Not necessarily. It could be a particularly tricky and critical piece of code that they want to ensure nobody is "auto-merging" into oblivion.

By putting a mutex on it, you are forced to re-evaluate the state when you obtain the lock. You can't sneak in a change in front of somebody else's change, requiring them to re-evaluate (or, worse, merge and hope).

If it was required for modules all over, it would be broken process. For a single module, I can understand it.

Good question - though I don't think it's a problem of broken process, but an absence of processes like you listed above. That's when these types of "solutions" are devised/used.

Two things I've learned in my years as a developer:

1. Sometimes the best process is old fashioned communication between people with common sense.

2. Never underestimate the power of a rubber chicken.

>1. Sometimes the best process is old fashioned communication between people with common sense.

I most wholeheartedly agree. Git, or a Source Control Shingle cannot replace effective communication. In fact, a solving a merge conflict is much more painful than a quick discussion.

VSS did this with all files by default. Does that put VSS way ahead of its time? :)

I'd actually take a Shingle over VSS. At least a shingle can't crash and corrupt all your revision metadata.

No. God no.