Version Control
This page lists version control tools. If you are new to programming,
you may not yet understand how vital it is that you learn to use these
tools. But if you ever found that your previous version of the code
worked and you current version doesn’t, now you know why you need to
use version control tools. While almost all version control tools
work for nearly any language (and so, strictly speaking, these tools
are not specific to the C language) they are so important that they
justify a wiki entry here.
Glossary
- distributed
- Describes tools that can be used by multiple people in different
places
- These tools don’t require people to have access to a shared
storage (drive, folder) and often support asynchronous ways of
contributing changes (email, pull requests, etc.)
- Most of these tools allow a develoiper to check in a change
“locally” without committing to making it visible yet to
everybody. This means that you can use the tool to
version-control work that is not “finished” yet.
- branching
- Allows you to manage multiple versions of the code at the same
time, and modify any of them. For example:
- If you have two versions of your code in use by customers,
keeping those on separate beanches allows you to make updates
to both versions (e.g. bug-fixes for older releases)
- Tools that suport “local” branches allow you to switch between
working on multiple things before either is “finished”. For
example to work on two features in paralle, or to switch from
working on a feature to making an emergency bug-fix
- merge
- The act of incorporating the changes on a branch (or just a
single change) into another branch.
- Often also describes the process of reconciling two
apparently-divergent copies of a file when performing a branch
merge
- git
- Today, this is the de-facto industry standard. Essentially
everybody should learn this even if they also have access to
something else.
- This is the tool that powers GitHub, GitLab and so on.
- Beej’s Guide to Git
- The Git Parable
- Mercurial
- [Piper](https://en.wikipedia.org/wiki/Piper_(source_control_system)
(migration from Perforce
P4);
many Googlers use
Fig,
a Mercurial front-end to Piper.
- Watchman -
Meta’s add-on for scaling Mercurial
Obsolescent
You can still use these today, and some people do, but apart from inertia there are likely few reasons to select these today for a new project
- Open Souce tools
- Distributed (or nearly so)
- CVS
- Originally invented by Dick Grune (perhaps otherwise more
famous for his excellent book Parsing
Techniques)
in 1986
- Allows geographically-separated developers to collaborate
Requires a server, and developers need online access to the
server to make commits or perform checkouts.
- Practical issues with access control, availability, safety
against abuse and CVS’s lack of support for private
branches were some of the things that drove widespread
adoption of git.
- Subversion (svn)
- Intended to be “CVS done right”, but setup was more
difficult than CVS. Perhaps for this reason, failed to
supplant CSV before git did that.
- DARCS - influential on other systems but
was never very popular itself.
- Non-Distributed
- RCS
(Wikipedia,
project page)
- Early 1980s replaacement for SCCS.
- Still feasible to use this for “local” version-control of
individual files, but this usage is probably uncommon now
that so many people understand how to use git.
Proprietary
Proprietary tools tend to go from “supported” through “end of support
announced” and then to “no support, obsolete” but we don’t track
end-of-support announcements so there are no obsolescent proprietary
tools listed here.
Obsolete
These are mainly useful for strdying preserved souce-code repositories
(for example old versions of Unix). Open-Source tools listed here are
not necessarily lacking support, but there is little reason to choose
to use them for new projects today.
- Open Source Tools
- SCCS
- Invented by Marc Rochkind in the early 1970s. Shipped with many versions of Unix (but was proprietary)
- Similar to RCS but designed differently (checkout is O(N) in
the total number of changes, while for RCS checkout is fast
for the current version and slow for older versions).
- Branching support exists but is very basic (e.g. very
difficult to tell if two versions of two files are on the same
“branch” - just convention)
- SCCS was the basis of Sun TeamWare and Sablime.
- Open-Souce versions:
- Proprietary