Version Control: Why pessimistic locking of source code is a very bad idea
When multiple developers work on a single project it is necessary to use software configuration management tools, the minimal requirement here is a version control system. The version control system ensures that the developers can concurrently work on the code without accidentally destroying the work of others. To ensure this there are 2 basic strategies a version control system can support:
- Lock-Modify-Unlock (LMU) ("Pessimistic Locking"): Before a developer can change a file he/she hast to obtain a lock, and while the file is locked no other developer can change the file. When the work is done the developers unlocks the file to make it available to all others again.
- Copy-Modify-Merge (CMM) ("Optimistic Locking"): When a developer starts working he/she obtains a copy of the repository (the "working copy"). All work is done in this working copy, and when some junk of work is finished the developer merges his/her changes back into the repository. If some other developer has also changed a file which should be merged back there is a conflict. The version control system will try to solve the conflict, and if it can't do so automatically it will ask the developer to resolve it.
Most version control systems support only one of these strategies, for example Microsoft's "Visual Source Safe" only supports LMU and the "Concurrent Version System" (CVS) supports only CMM. Newer versions of subversion (SVN) support both strategies, and I have already seen cases where this feature has been abused. When working with a version control system which supports both stragegies one has to decide which strategy is best for which parts of the project. Here is MNSHO about this topic:
- LMU: Should be used only for files where manual conflict resolving is impossible (i.e. binary files, like images, Word documents, ...).
- CMM: Should be used in all other cases, particularly for all kinds of text files (i.e. source code).
Pessimistic locking of is arguably a bad idea because:
- Merging conflicts in text files is a really trivial task. Everybody can do it, and it does not consume very much time.
- In a project with a reasonable project plan and good communication between the developers conflicts will occur wery seldom.
- LMU can cause sequentialization of tasks which could easily be parallelized, and this can cost a lot of time.
- With LMU, if a developer can not check in a file because it still has compile errors and he/she becomes sick, the file might be locked for a long time. This causes trouble for all other developers and the administrators of the version control system.
- Locking creates a false sense of security: When a developer locks a file and works on it while another developer works on another file, the system can be broken anyway if the two files depend on each other.