Version control is a vital element in every software project, since every project member responsible for software development or configuration management has to use it. Thus, the choice of the right tool should be well considered. With this choice comes the choice of a collaboration paradigm: optimistic version control or pessimistic locking of the resources contained in the project repository. Both paradigms offer a solution to resolving or avoiding conflicts when two developers want to access the same resource at the same time.
Optimistic Version Control
Optimistic version control is the default setting in prominent tools like CVS or Subversion. A conflict is created and resolved the following way:
- Persons A and B get resource X from the repository
- Person A checks his changes into the repository
- Person B tries to check in his changes and is alerted of a conflict
- Person B merges his changes into the version of X checked in by Person A
Pessimistic version control avoids conflicts altogether by locking resources.
- Person A gets resource X from the repository, locking it
- Person B tries to get resource X from the repository but cannot, since it is locked
- Person A checks in his changes into the repository, unlocking resource X
- Person B can now get resource X from the repository an do his changes
This technique is pessimistic in that it expects the worst, which in this case is persons A and B editing resource X at the same time.
Why Pessimism is bad
In my opinion, pessimistic version control is just a measure of some manager to let the poor developers feel who’s the boss. The term “pessimistic” alone should be enough to think about another solution (try explaining to someone not involved in software development why we are pessimistic about version control…).
The main reason for my opinion is the fact that while resources are locked by someone, no one else can work on these resources, effectively blocking the progress of everyone else, who just now needed to change something. Plus, if I want to change a resource someone else is currently blocking, I have to call this someone and tell him to drop me a note when he’s finished, which is organizational overhead. For resources that are changed often (like configuration files or central source files) this can be a severe problem!
I often hear the argument “But when a resource is locked, we don’t have to merge anymore. And merging is evil, because it is much work and error prone”. It is not. There are tools to help the developer to merge files. These tools are proven. In most cases you only have to look at the tools’ output an confirm it. Merging files only gets nasty when a file has completely changed…which is rarely the case.
Another argument for pessimistic locking is this: “In large teams, many people are working on the same repository. Thus, optimistic version control would result in a lot of merging”. Besides the previous argument that merging is neither difficult nor dangerous, a large team should work on a large project. What is the chance that 2 out of 20 developers try to access the same resource (out of 20 000) at the same time?
Additionally to the above argumentation for optimistic version control I have had some rather bad experiences with pessimistic version control. Someone always forgets to check his sources back into the repository. Very frustrating if this someone is not reachable by phone because he’s sick or on vacation. Furthermore, not all tools boasting the locking feature really work. In my case, the locking mechanism didn’t always work and you had to merge anyways. Or the tool let the developer choose whether to lock or not. This made it possible for Person B to check in his changes while Person A had the resource locked…automatically creating a branch without letting the developer know this. I don’t want to know what changes were lost due to this bug… . Very ugly, indeed.
So…why not let the developers actually work instead of letting them twiddle their thumbs while waiting for someone to release a lock?