Version Control
What is "version control," and why should you be concerned about it? Version control is a method of tracking changes to a file or set of files over time so that you may go back in time and recall specific versions. In the examples in this book, the files being version controlled are software source code, but you may do this with practically any sort of file on a computer.
Local Version Control Systems
Copying
files into another directory (maybe a time-stamped directory, if they're
clever) is a common version-control approach used by many people. Because it is
so simple, this strategy is immensely popular, yet it is also extremely
error-prone. It's easy to lose track of which directory you're in and write to
the wrong file or copy over data you didn't intend to copy over.
To address this problem, programmers created local VCSs with a simple database that tracked all file changes under revision control.
Centralized Version Control Systems
The
necessity to interact with developers on other systems is the next big
difficulty that people face. Centralized Version Control Systems (CVCSs) were
created to address this issue. These systems (like CVS, Subversion, and
Perforce) feature a central server that holds all of the versioned files, as well as several clients that check out files from that central
location. This has been the standard for version control for many years.
This
arrangement has a number of advantages over local VCSs. For example, everyone
on the project is aware of what everyone else is doing to some extent.
Administrators have fine-grained control over who has access to what, and
administering a CVCS is significantly easier than dealing with local databases
on each client.
However, there are some severe drawbacks to this configuration. The most obvious is the centralized server's role as a single point of failure. If that server goes down for an hour, no one can collaborate or save versioned changes to whatever they're working on during that time. If the central database's hard disk becomes corrupted, and sufficient backups aren't kept, you lose everything — the whole history of the project, except any single snapshots users have on their local workstations. Local VCSs have the same issue: storing the complete project history in a single location puts you in danger of losing everything.
Distributed Version Control Systems
This is
when DVCSs (Distributed Version Control Systems) come in handy. Clients of a
distributed version control system (DVCS) (such as Git, Mercurial, Bazaar, or
Darcs) don't merely check out the most recent snapshot of the files; they fully
mirror the repository, including its whole history. As a result, if any server
goes down and these systems were cooperating through it, any of the client
repositories can be copied back up to the server to get it back online. Every
clone is a complete backup of all data.
Furthermore, many of these solutions function well with several remote repositories, allowing you to collaborate with different groups of people in different ways within the same project at the same time. This enables you to create procedures such as hierarchical models that aren't available in centralized systems.
Comments
Post a Comment