I'm used to version control, in particular I currently use Mercurial. I have some doubts about how to make it work in large teams, where there is a good probability of having more people working on the same file.
Let me make an example with Mercurial (but any decentralized system will be more or less the same). Say we have a central server and three developers Alice, Bob and Carl. The three decide to start working at the same moment and they all pull from the server. By chance it happens that they are working on the same file.
Alice finishes first, and push her changes to the server. Then both Bob and Carl finish, more or less at the same time. Before pushing, they check whether there is something new, and find Alice's commit. So they pull it, and each one merges the changes locally. Then Bob pushes it and Carl pushes its changes.
What happens here is that on the server there are two heads: one by Bob and one by Carl, and both include merges with Alice's work. Whoever now pulls from the server will find a little mess. Of course one can just merge Bob and Carl heads, but that may not be as simple. Bob and Carl may have had different ideas on how to merge with Alice's work.
As soon as more people start working on the project, things can go even worse. So, while in theory I understand how merges are supposed to work, it is not clear to me how to make things manageable in a large project.
How do people manage to resolve conflicts when there are many people working on the same file, possibly having done different merges in different orders?