Just forget about the centralized version control systems. Let's be honest, centralized version control systems are relics of the past. In the times when most of us have the opportunities to work remotely full-time, it is unreasonable to be constrained by all the deficiencies of a centralized VCS. For instance, with CVS or SVN, you can't track the changes when offline. And that's silly.
What should you do when the internet connection at your workplace is temporarily broken or the central repository goes down? Should you forget about all your workflow and just allow changes to pile up until the situation changes, and then just commit them as one huge blob of unstructured updates? No!
Also, most of the centralized version control systems do not handle branching schemes efficiently. And branching is a very useful technique that allows you to limit the number of merge conflicts in the projects where many people work on multiple features. Branching in SVN is so ridiculous that most of the developers try to avoid it at all costs. Instead, most of the centralized VCSes provide some file locking primitives that should be considered the anti-pattern for any version system.
The sad truth about every version control tool (and software in general) is that, if it contains a dangerous option, someone in your team will start using it on a daily basis eventually. And locking is one such feature that, in return for less merge conflicts, will drastically reduce the productivity of your whole team. By choosing a version control system that does not allow for such bad workflows, you are creating an environment that makes it more likely that your developers will use it effectively.
In the next section, the Git distributed version control system is explained.