Version Control is a system which tracks changes to a set of files over time in order to recall specific versions from the past at some point in the future. It will allow a development team to revert files to a previous (sane) state, identify who made changes to a file, compare and track changes over time, and more. In short, it provides a way to recover from disaster in the development cycle. Developers need to collaborate with other developers on other parts of a system and version control allows them to do so safely.
Centralized Version Control systems, such as CVS or SVN, have a single server which contains all the versioned files in the system, and any number of clients which check these files in and out from that central place. SVN manages files and directories, allowing developers to modify and manage the same set of data from their respective locations and tracks changes by version number so any incorrect change can be backed out. Developers can be aware of what files other developers are working on within the system, and administrators can control what parts of the project individual developers can access. A drawback of the centralized version control system is that it contains a single point of failure – should the central server go down, no one can save versioned changes or collaborate while it is down.
Distributed Version Control systems, such as Git, Mercurial, or Bazaar, fully mirror the repository at each client. If the server crashes, it can be restored from any of the client repositories. Essentially, every check out to a client is a full backup of all the data. Distributed version control leverages the power of high-speed network connections and low storage costs which de-centralizes the store of data. Each user keeps and operates a deep local version history. Changesets are traded directly between users’ local data stores, rather than a centralized master data store, offering incredible performance for day-to-day operations.