bos@16: \chapter{Introduction} bos@16: \label{chap:intro} bos@16: bos@217: \section{About revision control} bos@155: bos@219: Revision control is the process of managing multiple versions of a bos@219: piece of information. In its simplest form, this is something that bos@219: many people do by hand: every time you modify a file, save it under a bos@219: new name that contains a number, each one higher than the number of bos@219: the preceding version. bos@217: bos@217: Manually managing multiple versions of even a single file is an bos@217: error-prone task, though, so software tools to help automate this bos@217: process have long been available. The earliest automated revision bos@217: control tools were intended to help a single user to manage revisions bos@219: of a single file. Over the past few decades, the scope of revision bos@219: control tools has expanded greatly; they now manage multiple files, bos@219: and help multiple people to work together. The best modern revision bos@219: control tools have no problem coping with thousands of people working bos@219: together on projects that consist of hundreds of thousands of files. bos@217: bos@217: \subsection{Why use revision control?} bos@217: bos@217: There are a number of reasons why you or your team might want to use bos@217: an automated revision control tool for a project. bos@217: \begin{itemize} bos@219: \item It will track the history and evolution of your project, so you bos@219: don't have to. For every change, you'll have a log of \emph{who} bos@219: made it; \emph{why} they made it; \emph{when} they made it; and bos@219: \emph{what} the change was. bos@219: \item When you're working with other people, revision control software bos@219: makes it easier for you to collaborate. For example, when people bos@219: more or less simultaneously make potentially incompatible changes, bos@219: the software will help you to identify and resolve those conflicts. bos@217: \item It can help you to recover from mistakes. If you make a change bos@217: that later turns out to be in error, you can revert to an earlier bos@217: version of one or more files. In fact, a \emph{really} good bos@217: revision control tool will even help you to efficiently figure out bos@217: exactly when a problem was introduced (see bos@217: section~\ref{sec:undo:bisect} for details). bos@218: \item It will help you to work simultaneously on, and manage the drift bos@218: between, multiple versions of your project. bos@217: \end{itemize} bos@218: Most of these reasons are equally valid---at least in theory---whether bos@218: you're working on a project by yourself, or with a hundred other bos@218: people. bos@218: bos@218: A key question about the practicality of revision control at these two bos@218: different scales (``lone hacker'' and ``huge team'') is how its bos@218: \emph{benefits} compare to its \emph{costs}. A revision control tool bos@218: that's difficult to understand or use is going to impose a high cost. bos@218: bos@219: A five-hundred-person project is likely to collapse under its own bos@219: weight almost immediately without a revision control tool and process. bos@219: In this case, the cost of using revision control might hardly seem bos@219: worth considering, since \emph{without} it, failure is almost bos@219: guaranteed. bos@218: bos@218: On the other hand, a one-person ``quick hack'' might seem like a poor bos@218: place to use a revision control tool, because surely the cost of using bos@218: one must be close to the overall cost of the project. Right? bos@218: bos@218: Mercurial uniquely supports \emph{both} of these scales of bos@218: development. You can learn the basics in just a few minutes, and due bos@218: to its low overhead, you can apply revision control to the smallest of bos@218: projects with ease. Its simplicity means you won't have a lot of bos@218: abstruse concepts or command sequences competing for mental space with bos@218: whatever you're \emph{really} trying to do. At the same time, bos@218: Mercurial's high performance and peer-to-peer nature let you scale bos@218: painlessly to handle large projects. bos@217: bos@219: No revision control tool can rescue a poorly run project, but a good bos@219: choice of tools can make a huge difference to the fluidity with which bos@219: you can work on a project. bos@219: bos@217: \subsection{The many names of revision control} bos@217: bos@217: Revision control is a diverse field, so much so that it doesn't bos@217: actually have a single name or acronym. Here are a few of the more bos@217: common names and acronyms you'll encounter: bos@217: \begin{itemize} bos@217: \item Revision control (RCS) bos@219: \item Software configuration management (SCM), or configuration management bos@218: \item Source code management bos@219: \item Source code control, or source control bos@217: \item Version control (VCS) bos@217: \end{itemize} bos@217: Some people claim that these terms actually have different meanings, bos@217: but in practice they overlap so much that there's no agreed or even bos@217: useful way to tease them apart. bos@155: bos@219: \section{A short history of revision control} bos@155: bos@218: The best known of the old-time revision control tools is SCCS (Source bos@218: Code Control System), which Marc Rochkind wrote at Bell Labs, in the bos@218: early 1970s. SCCS operated on individual files, and required every bos@218: person working on a project to have access to a shared workspace on a bos@218: single system. Only one person could modify a file at any time; bos@218: arbitration for access to files was via locks. It was common for bos@218: people to lock files, and later forget to unlock them, preventing bos@218: anyone else from modifying those files without the help of an bos@218: administrator. bos@218: bos@218: Walter Tichy developed a free alternative to SCCS in the early 1980s; bos@218: he called his program RCS (Revison Control System). Like SCCS, RCS bos@218: required developers to work in a single shared workspace, and to lock bos@218: files to prevent multiple people from modifying them simultaneously. bos@218: bos@218: Later in the 1980s, Dick Grune used RCS as a building block for a set bos@218: of shell scripts he initially called cmt, but then renamed to CVS bos@218: (Concurrent Versions System). The big innovation of CVS was that it bos@218: let developers work simultaneously and somewhat independently in their bos@218: own personal workspaces. The personal workspaces prevented developers bos@218: from stepping on each other's toes all the time, as was common with bos@218: SCCS and RCS. Each developer had a copy of every project file, and bos@218: could modify their copies independently. They had to merge their bos@218: edits prior to committing changes to the central repository. bos@218: bos@218: Brian Berliner took Grune's original scripts and rewrote them in~C, bos@218: releasing in 1989 the code that has since developed into the modern bos@218: version of CVS. CVS subsequently acquired the ability to operate over bos@218: a network connection, giving it a client/server architecture. CVS's bos@218: architecture is centralised; only the server has a copy of the history bos@218: of the project. Client workspaces just contain copies of recent bos@218: versions of the project's files, and a little metadata to tell them bos@218: where the server is. CVS has been enormously successful; it is bos@218: probably the world's most widely used revision control system. bos@218: bos@218: In the early 1990s, Sun Microsystems developed an early distributed bos@218: revision control system, called TeamWare. A TeamWare workspace bos@218: contains a complete copy of the project's history. TeamWare has no bos@218: notion of a central repository. (CVS relied upon RCS for its history bos@218: storage; TeamWare used SCCS.) bos@218: bos@218: As the 1990s progressed, awareness grew of a number of problems with bos@218: CVS. It records simultaneous changes to multiple files individually, bos@218: instead of grouping them together as a single logically atomic bos@218: operation. It does not manage its file hierarchy well; it is easy to bos@218: make a mess of a repository by renaming files and directories. Worse, bos@218: its source code is difficult to read and maintain, which made the bos@218: ``pain level'' of fixing these architectural problems prohibitive. bos@218: bos@218: In 2001, Jim Blandy and Karl Fogel, two developers who had worked on bos@218: CVS, started a project to replace it with a tool that would have a bos@218: better architecture and cleaner code. The result, Subversion, does bos@218: not stray from CVS's centralised client/server model, but it adds bos@218: multi-file atomic commits, better namespace management, and a number bos@218: of other features that make it a generally better tool than CVS. bos@218: Since its initial release, it has rapidly grown in popularity. bos@218: bos@218: More or less simultaneously, Graydon Hoare began working on an bos@218: ambitious distributed revision control system that he named Monotone. bos@218: While Monotone addresses many of CVS's design flaws and has a bos@218: peer-to-peer architecture, it goes beyond earlier (and subsequent) bos@218: revision control tools in a number of innovative ways. It uses bos@218: cryptographic hashes as identifiers, and has an integral notion of bos@218: ``trust'' for code from different sources. bos@218: bos@218: Mercurial began life in 2005. While a few aspects of its design are bos@218: influenced by Monotone, Mercurial focuses on ease of use, high bos@218: performance, and scalability to very large projects. bos@155: bos@219: \section{Trends in revision control} bos@219: bos@219: There has been an unmistakable trend in the development and use of bos@219: revision control tools over the past four decades, as people have bos@219: become familiar with the capabilities of their tools and constrained bos@219: by their limitations. bos@219: bos@219: The first generation began by managing single files on individual bos@219: computers. Although these tools represented a huge advance over bos@219: ad-hoc manual revision control, their locking model and reliance on a bos@219: single computer limited them to small, tightly-knit teams. bos@219: bos@219: The second generation loosened these constraints by moving to bos@219: network-centered architectures, and managing entire projects at a bos@219: time. As projects grew larger, they ran into new problems. With bos@219: clients needing to talk to servers very frequently, server scaling bos@219: became an issue for large projects. An unreliable network connection bos@219: could prevent remote users from being able to talk to the server at bos@219: all. As open source projects started making read-only access bos@219: available anonymously to anyone, people without commit privileges bos@219: found that they could not use the tools to interact with a project in bos@219: a natural way, as they could not record their changes. bos@219: bos@219: The current generation of revision control tools is peer-to-peer in bos@219: nature. All of these systems have dropped the dependency on a single bos@219: central server, and allow people to distribute their revision control bos@219: data to where it's actually needed. Collaboration over the Internet bos@219: has moved from constrained by technology to a matter of choice and bos@219: consensus. Modern tools can operate offline indefinitely and bos@219: autonomously, with a network connection only needed when syncing bos@219: changes with another repository. bos@219: bos@219: \section{A few of the advantages of distributed revision control} bos@219: bos@219: Even though distributed revision control tools have for several years bos@219: been as robust and usable as their previous-generation counterparts, bos@219: people using older tools have not yet necessarily woken up to their bos@219: advantages. There are a number of ways in which distributed tools bos@219: shine relative to centralised ones. bos@219: bos@219: For an individual developer, distributed tools are almost always much bos@219: faster than centralised tools. This is for a simple reason: a bos@219: centralised tool needs to talk over the network for many common bos@219: operations, because most metadata is stored in a single copy on the bos@219: central server. A distributed tool stores all of its metadata bos@219: locally. All else being equal, talking over the network adds overhead bos@219: to a centralised tool. Don't underestimate the value of a snappy, bos@219: responsive tool: you're going to spend a lot of time interacting with bos@219: your revision control software. bos@219: bos@219: Distributed tools are indifferent to the vagaries of your server bos@219: infrastructure, again because they replicate metadata to so many bos@219: locations. If you use a centralised system and your server catches bos@219: fire, you'd better hope that your backup media are reliable, and that bos@219: your last backup was recent and actually worked. With a distributed bos@219: tool, you have many backups available on every contributor's computer. bos@219: bos@219: The reliability of your network will affect distributed tools far less bos@219: than it will centralised tools. You can't even use a centralised tool bos@219: without a network connection, except for a few highly constrained bos@219: commands. With a distributed tool, if your network connection goes bos@219: down while you're working, you may not even notice. The only thing bos@219: you won't be able to do is talk to repositories on other computers, bos@219: something that is relatively rare compared with local operations. If bos@219: you have a far-flung team of collaborators, this may be significant. bos@219: bos@219: If you take a shine to an open source project and decide that you bos@219: would like to start hacking on it, and that project uses a distributed bos@219: revision control tool, you are at once a peer with the people who bos@219: consider themselves the ``core'' of that project. If they publish bos@219: their repositories, you can immediately copy their project history, bos@219: start making changes, and record your work, using the same tools in bos@219: the same ways as insiders. By contrast, with a centralised tool, you bos@219: must use the software in a ``read only'' mode unless someone grants bos@219: you permission to commit changes to their central server. Until then, bos@219: you won't be able to record changes, and your local modifications will bos@219: be at risk of corruption any time you try to update your client's view bos@219: of the repository. bos@155: bos@155: \subsection{For open source projects} bos@155: bos@155: \subsection{For commercial projects} bos@155: bos@155: \subsection{Myths about distributed revision control} bos@155: bos@219: \subsubsection{Distributed tools encourage projects to fork} bos@219: bos@155: \section{Why choose Mercurial?} bos@155: bos@16: bos@16: %%% Local Variables: bos@16: %%% mode: latex bos@16: %%% TeX-master: "00book" bos@16: %%% End: