Automation - The Practice of Cloud System Administration - page 264

12.7.2 Version Control Systems
A version control system (VCS) is a central repository for storing, accessing, and updating
source code. Having all source code in one place makes it easier to collaborate and easier
to centralize functions such as backups, build processes, and so on. A VCS stores the his-
tory of each file, including all the changes ever made. As a consequence, it is possible to
see what the software looked like at a particular date, revert changes, and so on. Although
version control systems were originally used for source code control, a VCS can store any
file, not just source code.
VCS frameworks all have a similar workflow. Suppose you want to make a change to
a system. You “check out” the source code, thus copying the entire source to your local
directory. You can then edit it as needed. When your work is complete, you “commit” or
“check out” your changes.
Older VCS frameworks permit only one person to check out a particular project at a
given time so that people can't create conflicting changes. Newer systems permit multiple
people to check out the same project. The first person to check in his or her changes has
it easy; all of the others go through a process of merging their changes with past changes.
VCS software helps with merges, doing non-overlapping merges automatically and bring-
ing up an editor for you to manually merge the rest.
Adistributedversioncontrolsystem(DVCS)isanewbreedofVCS.InaDVCS,every-
one has his or her own complete repository. Sets of changes are transmitted between re-
positories. Check-outs don't just give you a copy of the source code at a particular version,
but create a local copy of the entire repository including the entire revision history. You
can check in changes to the local repository independently of what is going on in the cent-
ral system. You then merge a group of such changes to the master repository when you
are done. This democratizes source code control. Before DVCS, you could make only one
change at a time and that change had to be approved by whoever controlled the repository.
It was difficult to proceed with the next change until the first change was accepted by the
repository owner. In a DVCS, you are the master of your own repository. You do devel-
opment in parallel with the main repository. Changes made to the main repository can be
pulled into your repository in a controlled manner and only when you want to import the
changes. Changes you make in your repository can be merged upstream to the main repos-
itory when desired, or not at all.
A VCS should not be used only for source code; that is, configuration files must also be
revision controlled. When automation or use of tools involves configuration file changes,
youshouldautomate thesteps ofchecking theconfigfile outofversion control, modifying
it, and then checking it back in. Tools should not be allowed to modify config files outside
of the VCS.