Version control is a system that records changes to a file or set of
files over time so that you can recall specific versions later.
It allows you to revert files back to a previous state, revert the
entire project back to a previous state, compare changes over time, see who
last modified something that might be causing a problem, who introduced an
issue and when, and more. Using a VCS also generally means that if you screw
things up or lose files, you can easily recover.
Centralized
Version Control Systems
These systems, such as CVS, Subversion, and Perforce, have a single
server that contains all the versioned files, and a number of clients that
check out files from that central place. For many years, this has been the
standard for version control.
This setup
offers many advantages, especially over local VCSs. For example, everyone knows
to a certain degree what everyone else on the project is doing. Administrators
have fine-grained control over who can do what; and it’s far easier to
administer a CVCS than it is to deal with local databases on every client.
However,
this setup also has some serious downsides. The most obvious is the single
point of failure that the centralized server represents. If that server goes
down for an hour, then during that hour nobody can collaborate at all or save
versioned changes to anything they’re working on. If the hard disk the central
database is on becomes corrupted, and proper backups haven’t been kept, you
lose absolutely everything – the entire history of the project except whatever
single snapshots people happen to have on their local machines. Local VCS
systems suffer from this same problem – whenever you have the entire history of
the project in a single place, you risk losing everything.