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?
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!
However, 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.