Centralized version control is a model in which one central server holds the single canonical copy of a project’s versioned files and history. The git book, written by the git project, describes these centralized version control systems, naming CVS, Subversion, and Perforce as examples, and explains that they have “a single server that contains all the versioned files” while clients “check out files from that central place.”
The git book lists the advantages of this arrangement. Everyone on a project can see what others are doing, administrators have fine-grained control over who can do what, and a single server is easier to administer than a version database on every client. For years, the book notes, this was the standard for version control.
It also names the weaknesses. The central server is a single point of failure: if it goes down, no one can collaborate or save versioned changes during that time, and if its database is corrupted without good backups the entire project history can be lost. The git book contrasts this with distributed systems, in which clients fully mirror the repository including its full history.
The Subversion book describes the same centralized model from the inside, presenting a central repository that clients commit to and check out from. Centralized version control defined the CVS and Subversion era of the 1990s and 2000s, before distributed version control, led by git, became the dominant approach.