This is an often proposed view: version control only works when individual files can only be worked on through exclusive or sometimes multiple checkouts.
The problem with this is that very few systems are factored in such a way that this source control model maps onto the file storage.
Here are some specific points:
Different development tools have different constraints: Java for one pretty much mandates which file you will need to be editing to change a certain class - tough if two people need to make changes.
Many development tools have linked files which can only really be modified as one unit: exactly how the checkout of the required set of files is done can be tricky. One may not know in advance.
Although it would be nice if all projects were well factored so that changes can be made through surgical strikes on the source base, life isn't like that and to get to the promised land you may well have to go through some wide-ranging refactorings requiring changes to many files.
Why does this matter?
Because even for small teams the "deadly embrace" where people are deadlocked waiting on files to come free can happen very quickly.
The temptation to improvise in the interests of getting the job done can become overwhelming.
The things that might happen then are:
- teams "stepping outside" source control
- less robust or verifiable coding techniques becoming "house style" to allow for changes to be "smuggled in" without needing the proper access to all affected files
- code snippets getting emailed around for manual merging
None of the above are good.
