title: Why avoid pessimistic locking in a version control system?
body: <p>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.</p>
  
  <p>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?</p>