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?

  • There's no reason for locking in a DVCS. When you clone a repository, you get the entire repository, including all of the history. – user11946 Jan 23 '13 at 17:36

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.


It's not an anti-pattern because not everyone gets to work with text files. As this person points out, you might be using an application that creates binary files in some undocumented proprietary format that you can't easily merge afterwards.

A simpler case of that is images, it only ever makes sense for one person to work on it at a time. Without locking you need good team communication so everyone knows what everyone else is working on and avoid stepping on each other's toes. Communication is important in every team, but relying on it to avoid work collisions can scale poorly for large teams.

Even if you do get to work with text files, it may still be inconvenient because of context (thank you @mike). For example, take a look at this question: Git merging within a line, specifically:

With a LaTeX document this is particularly annoying, as the common habit when writing LeTeX is to write a full paragraph per line and just let your text editor handle word wrapping when displaying for you.

There is a workable solution proposed to that question, but when you work with human languages, things often get tricky.

  • 2
    It often doesn't make sense for multiple people to edit and merge an English passage. – mike30 Jan 23 '13 at 19:46
  • A paragraph per line doesn’t mean you can’t merge. It means you need a merge tool that doesn’t force everything into a line-based view. :) – Marnen Laibow-Koser Jun 15 '18 at 1:42

Most binary file formats can't be merged by source control. If it is changed by two people at the same time, the last one to check it in "wins." Locking can be useful in that situation, although a lot of teams use some other means of communication (like assigning owners) to prevent such a problem.

Outside of binary files, most people would agree that VCS locking is an anti-pattern, although it obviously has its advocates. It often leads to people doing merges outside of version control, or making local changes "just for debugging purposes" in a file someone else has locked, then neglecting to check it in. Merging can be annoying, but dealing with locks is usually more annoying. That's why most centralized VCS nowadays allows you to selectively lock certain files and not others.

  • +1 for binary files. I've used svn locks frequently when creating diagrams, figures, etc for papers and journal articles. – Sam Miller Jan 23 '13 at 20:19

I would highly recommend reading Version Control by Example: http://www.ericsink.com/vcbe/ It explains very clearly the concepts of various systems, including when locking works and when it doesn't (which is indeed for non-text files and when merging can't be resolved.) True locking isn't possible (due to offline access) but some kind of lock concept can be useful to prevent overwriting someone elses work.

(It also points out you can still use a central server in a git-setup, and it might make sense to do so. Distributed doesn't mean one of the repositories can't have a special meaning.)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.