1.1 --- a/en/intro.tex	Thu May 10 13:24:25 2007 -0700
     1.2 +++ b/en/intro.tex	Thu May 10 17:21:09 2007 -0700
     1.3 @@ -26,11 +26,11 @@
     1.4  an automated revision control tool for a project.
     1.5  \begin{itemize}
     1.6  \item The software gives you a unified way of working with your
     1.7 -  project's files, and a single place to look in.
     1.8 -\item When you're working with other people, it will make it easier
     1.9 -  for you to collaborate.  When people more or less simultaneously
    1.10 -  make potentially incompatible changes, the software will help you to
    1.11 -  identify and resolve those conflicts.
    1.12 +  project's files.
    1.13 +\item When you're working with other people, it makes it easier for
    1.14 +  you to collaborate.  For example, when people more or less
    1.15 +  simultaneously make potentially incompatible changes, the software
    1.16 +  will help you to identify and resolve those conflicts.
    1.17  \item It will track the history of your project.  For every change,
    1.18    you'll have a log of \emph{who} made it; \emph{why} they made it;
    1.19    \emph{when} they made it; and \emph{what} the change was.
    1.20 @@ -40,9 +40,36 @@
    1.21    revision control tool will even help you to efficiently figure out
    1.22    exactly when a problem was introduced (see
    1.23    section~\ref{sec:undo:bisect} for details).
    1.24 -\item It will help you to work simultaneously on multiple versions of
    1.25 -  your project.
    1.26 +\item It will help you to work simultaneously on, and manage the drift
    1.27 +  between, multiple versions of your project.
    1.28  \end{itemize}
    1.29 +Most of these reasons are equally valid---at least in theory---whether
    1.30 +you're working on a project by yourself, or with a hundred other
    1.31 +people.
    1.32 +
    1.33 +A key question about the practicality of revision control at these two
    1.34 +different scales (``lone hacker'' and ``huge team'') is how its
    1.35 +\emph{benefits} compare to its \emph{costs}.  A revision control tool
    1.36 +that's difficult to understand or use is going to impose a high cost.
    1.37 +
    1.38 +For example, a five-hundred-person project is likely to collapse under
    1.39 +its own weight almost immediately without a revision control tool and
    1.40 +process.  In this case, the cost of using revision control might
    1.41 +hardly seem worth considering, since \emph{without} it, failure is
    1.42 +almost guaranteed.
    1.43 +
    1.44 +On the other hand, a one-person ``quick hack'' might seem like a poor
    1.45 +place to use a revision control tool, because surely the cost of using
    1.46 +one must be close to the overall cost of the project.  Right?
    1.47 +
    1.48 +Mercurial uniquely supports \emph{both} of these scales of
    1.49 +development.  You can learn the basics in just a few minutes, and due
    1.50 +to its low overhead, you can apply revision control to the smallest of
    1.51 +projects with ease.  Its simplicity means you won't have a lot of
    1.52 +abstruse concepts or command sequences competing for mental space with
    1.53 +whatever you're \emph{really} trying to do.  At the same time,
    1.54 +Mercurial's high performance and peer-to-peer nature let you scale
    1.55 +painlessly to handle large projects.
    1.56  
    1.57  \subsection{The many names of revision control}
    1.58  
    1.59 @@ -53,14 +80,84 @@
    1.60  \item Configuration management (CM)
    1.61  \item Revision control (RCS)
    1.62  \item Software configuration management (SCM)
    1.63 +\item Source code management
    1.64 +\item Source control
    1.65  \item Version control (VCS)
    1.66  \end{itemize}
    1.67  Some people claim that these terms actually have different meanings,
    1.68  but in practice they overlap so much that there's no agreed or even
    1.69  useful way to tease them apart.
    1.70  
    1.71 -\section{The hierarchy of revision control}
    1.72 +\section{A short history and hierarchy of revision control}
    1.73  
    1.74 +The best known of the old-time revision control tools is SCCS (Source
    1.75 +Code Control System), which Marc Rochkind wrote at Bell Labs, in the
    1.76 +early 1970s.  SCCS operated on individual files, and required every
    1.77 +person working on a project to have access to a shared workspace on a
    1.78 +single system.  Only one person could modify a file at any time;
    1.79 +arbitration for access to files was via locks.  It was common for
    1.80 +people to lock files, and later forget to unlock them, preventing
    1.81 +anyone else from modifying those files without the help of an
    1.82 +administrator.  
    1.83 +
    1.84 +Walter Tichy developed a free alternative to SCCS in the early 1980s;
    1.85 +he called his program RCS (Revison Control System).  Like SCCS, RCS
    1.86 +required developers to work in a single shared workspace, and to lock
    1.87 +files to prevent multiple people from modifying them simultaneously.
    1.88 +
    1.89 +Later in the 1980s, Dick Grune used RCS as a building block for a set
    1.90 +of shell scripts he initially called cmt, but then renamed to CVS
    1.91 +(Concurrent Versions System).  The big innovation of CVS was that it
    1.92 +let developers work simultaneously and somewhat independently in their
    1.93 +own personal workspaces.  The personal workspaces prevented developers
    1.94 +from stepping on each other's toes all the time, as was common with
    1.95 +SCCS and RCS.  Each developer had a copy of every project file, and
    1.96 +could modify their copies independently.  They had to merge their
    1.97 +edits prior to committing changes to the central repository.
    1.98 +
    1.99 +Brian Berliner took Grune's original scripts and rewrote them in~C,
   1.100 +releasing in 1989 the code that has since developed into the modern
   1.101 +version of CVS.  CVS subsequently acquired the ability to operate over
   1.102 +a network connection, giving it a client/server architecture.  CVS's
   1.103 +architecture is centralised; only the server has a copy of the history
   1.104 +of the project.  Client workspaces just contain copies of recent
   1.105 +versions of the project's files, and a little metadata to tell them
   1.106 +where the server is.  CVS has been enormously successful; it is
   1.107 +probably the world's most widely used revision control system.
   1.108 +
   1.109 +In the early 1990s, Sun Microsystems developed an early distributed
   1.110 +revision control system, called TeamWare.  A TeamWare workspace
   1.111 +contains a complete copy of the project's history.  TeamWare has no
   1.112 +notion of a central repository.  (CVS relied upon RCS for its history
   1.113 +storage; TeamWare used SCCS.)
   1.114 +
   1.115 +As the 1990s progressed, awareness grew of a number of problems with
   1.116 +CVS.  It records simultaneous changes to multiple files individually,
   1.117 +instead of grouping them together as a single logically atomic
   1.118 +operation.  It does not manage its file hierarchy well; it is easy to
   1.119 +make a mess of a repository by renaming files and directories.  Worse,
   1.120 +its source code is difficult to read and maintain, which made the
   1.121 +``pain level'' of fixing these architectural problems prohibitive.
   1.122 +
   1.123 +In 2001, Jim Blandy and Karl Fogel, two developers who had worked on
   1.124 +CVS, started a project to replace it with a tool that would have a
   1.125 +better architecture and cleaner code.  The result, Subversion, does
   1.126 +not stray from CVS's centralised client/server model, but it adds
   1.127 +multi-file atomic commits, better namespace management, and a number
   1.128 +of other features that make it a generally better tool than CVS.
   1.129 +Since its initial release, it has rapidly grown in popularity.
   1.130 +
   1.131 +More or less simultaneously, Graydon Hoare began working on an
   1.132 +ambitious distributed revision control system that he named Monotone.
   1.133 +While Monotone addresses many of CVS's design flaws and has a
   1.134 +peer-to-peer architecture, it goes beyond earlier (and subsequent)
   1.135 +revision control tools in a number of innovative ways.  It uses
   1.136 +cryptographic hashes as identifiers, and has an integral notion of
   1.137 +``trust'' for code from different sources.
   1.138 +
   1.139 +Mercurial began life in 2005.  While a few aspects of its design are
   1.140 +influenced by Monotone, Mercurial focuses on ease of use, high
   1.141 +performance, and scalability to very large projects.
   1.142  
   1.143  \subsection{On a single system}
   1.144