Why avoid pessimistic locking in a version control system?

Question

Based on a few posts I've read concerning version control, it seems people think pessimistic locking in a version control system is a bad thing. Why? I understand that it prevents one developer from submitting a change while another has the file checked out, but so what? If your code files are so big that you constantly have more than one person working on them at the same time, I submit that you should reorganize your code. Break it up into smaller functional units.

Integration of concurrent code changes is a tedious and error-prone process even with the tools a good version control system provides to make it easier. I think it should be avoided if at all possible. So, why is pessimistic locking discouraged?

Answer 1

Software developers are always optimists -- just look at their estimating skils!

In practice we find conflicts are rare and the benefits of not having to worry about locking outweigh the occasional conflict resolution step.

Answer 2

1. Go play with Source Safe and have a developer leave for a two week vacation. Add to that the VSS admins not being around. Now you have a fix to be posted but you can't because of the developer
2. If you have multiple features and/or bug fixes being worked on. No matter how small your code is broken up, you will still have contention for a central file.

Answer 3

pessimistic locking is (personal experience) in the way of collaboration. It's sometimes easily replaced by good team communication. Just by saying "hey I'm gonna work on this few files for a while".

I've worked in teams of 2 to 6 people without locking and we never had a problem, beyond some usual and necessary merges.

I also worked once with locking in a Visual Source Safe hosted project. It was IMHO counter-productive.

Answer 4

• You don't always have the option to break files apart
  • Config Files
  • XML Files
• Even relatively small files can still contain distinct parts that more than one developer needs access to
  • Libraries
  • Utilities
• Merging Tools are much smarter than they have ever been
  • Conflicts are rather rare
• Reduces delays due to developers having files "accidentally" checked out

Answer 5

If a developer can't handle merging and fixing conflicts, he should be re-educated.

It is common for even small files to get conflicts, for example with JSPs one person (web developer) could be changing the layout code, and someone else could change the API for the model that the JSP is using.

Answer 6

It depends on your project and team generally. Pessimistic locking is good because it is easy to understand - one dev at a time, and no merging required!

Howvever, the bad thing about is is exactly that - one dev at a time. I have the situation right now where a colleague has gone on-site, and before he left, he checked everything out so that if he had to fix any bugs, he could return and check all his changes in.... great for him, lousy for me and the rest of the dev team at base.

If you can get around pessimistic locking in your team then its fine to use it, really, the biggest reason people hate it is because its Visual SourceSafe's default practice. If you're not confident in merging lots of changes, then you have another reason to use it - if you've ever used a optimistic locking SCM, and cocked up a merge, you'll know how hard it is to recover.

If you can handle merging, then optimistic locking is superior and I'd recommend it, but you don't have to hand your geek card in if you don't want to use it.

Answer 7

1. Bob needs to edit FooBar.java
2. John has it checked out for editing
3. Bob edits his local copy anyway and saves it as FooBar.java.bak
4. When John checks his in, Bob checks it out
5. Bob copies FooBar.java.bak over it and checks it in
6. John gets to reimplement his feature

I've seen it happen time and time again. Developers do this because this process is annoying:

1. Bob needs to edit FooBar.java
2. John has it checked out for editing
3. Bob has to wait twiddling his thumbs until John is done

Pessimistic locking feels like amateur hour, sorry.

Answer 8

if your code files are so big that you constantly have more than one person working on them at the same time

If this is the case it's time for 'human beings' to take charge and coordinate any changes. In the ideal case, and if your project management is any good, you will rarely hit a time where you're trying to change a locked file because someone will have coordinated things so this won't practically happen.

In other words you'll know 'Bob' is doing a large set of changes in components X/Y/Z, if you have a bug fix in component X you'll know to talk to Bob before trying to submit your changes.

As I say this is ideal ;)

Answer 9

Pessimistic locking is a good idea if serious conflicts are going to be likely. For most programming you won't see any serious conflicts, so pessimistic locking is fairly pointless. Exceptions to this would be if you are:

• Working on binary files where you can't really merge - art assets (models, textures, etc) are a good example.
• Working with non-technical users who don't know how to merge, and don't want to learn (mostly artists, but some technical writers will throw a fit about this too).
• Working on very large files which can't easily be merged or broken into smaller files due to the high degree of complexity (never seen a situation like that first hand, but I'm sure it's possible).

Otherwise...

Answer 10

Regarding the case with Bob and John, cooperative systems like svn do not prevent this scenario any more than a locking system does. I can 'update' FooBar.java, which satisfies svn that I have the latest edition, then delete that file locally and overwrite it with my own personal copy that I made without any regard for the baseline version, and check that in, happily destroying the other guy's changes. No system, locking or not, prevents this, so I do not see the point of even bringing it into the debate.

The real issue is deciding what your balance is between

likelihood of merge mistakes vs. inconvenience caused by people locking files

The notion that either a locking or non-locking system is "superior" is nonsense.

I've used VSS, in its default full locking mode, with 6 developers, and it worked like a dream. Occasionally, somebody would forget to release a lock and we'd have to hunt them down or break the lock manually and hand-merge when they returned, but this was very minimal. I've seen svn screw up its automatic merge more than once, such that I don't really trust it. It doesn't always flag a 'conflict' when two people have changed the same file in a way that cannot be automatically merged together.
Conversely, I've seen people get impatient with VSS's locks, edit their own copies, and sloppily check them in over the top of other peoples' code, and I've seen svn handily catch me when I might accidentally try to check something in that has been changed by somebody else since I last checked it out.

My point is, this is not a sensible debate to have. The success of either system comes down to how you manage the conflict points when they occur, not whether one system or the other is better.