Version Control – Is Locking/Unlocking in Version Control an Anti-Pattern?

distributed-developmentlocksversion control

Recently I've started using Git at work. Previously I've only ever used VSS (which has some problems) and so far, Git is orders of magnitude better.

The key differences here is that Git is distributed while VSS has a centralized "server" version, and that VSS uses a "checkout-lock-checkin" workflow while Git doesn't. The biggest problems we've had on working with code on our team relate to code being checked-out and unavailable to other people. This slows down work considerably, but I also know this isn't unique to VSS. Other source control systems like CVS apparently also lock files as part of their workflow.

Is there any good reason for locking to be part of a version control system? Or even a development workflow? Or perhaps locking practices should be considered bad practice and discouraged?

Best Answer

Is there any good reason for locking to be part of a version control system?

Yes, of course! It means that you NEVER have to worry about merging, which is a serious pain in any version control environment.

However, it was learned from bitter experience that the only pain bigger than merging is being forced to lock your team out from developing a file until you're ready to commit your entire development. Which is why modern VCSes, including TFS (and later versions of VSS, although it wasn't switched on by default), favour making merges easier over making them entirely unnecessary, at any cost.