1.1 --- a/en/intro.tex	Fri Jul 27 15:07:51 2007 -0700
     1.2 +++ b/en/intro.tex	Wed Aug 20 22:00:46 2008 +0200
     1.3 @@ -306,7 +306,7 @@
     1.4  fall over under the combined load of just a few dozen concurrent
     1.5  users.  Once again, the typical response tends to be an expensive and
     1.6  clunky replication facility.  Since the load on a central server---if
     1.7 -you have one at all---is orders of magnitude lower with a distributed
     1.8 +you have one at all---is many times lower with a distributed
     1.9  tool (because all of the data is replicated everywhere), a single
    1.10  cheap server can handle the needs of a much larger team, and
    1.11  replication to balance load becomes a simple matter of scripting.
    1.12 @@ -362,20 +362,24 @@
    1.13  have used every one of the revision control tools listed below, in
    1.14  most cases for several years at a time.
    1.15  
    1.16 +
    1.17  \subsection{Subversion}
    1.18  
    1.19  Subversion is a popular revision control tool, developed to replace
    1.20  CVS.  It has a centralised client/server architecture.
    1.21  
    1.22  Subversion and Mercurial have similarly named commands for performing
    1.23 -the same operations, so it is easy for a person who is familiar with
    1.24 -one to learn to use the other.  Both tools are portable to all popular
    1.25 +the same operations, so if you're familiar with one, it is easy to
    1.26 +learn to use the other.  Both tools are portable to all popular
    1.27  operating systems.
    1.28  
    1.29  Subversion lacks a history-aware merge capability, forcing its users
    1.30  to manually track exactly which revisions have been merged between
    1.31  branches.  If users fail to do this, or make mistakes, they face the
    1.32  prospect of manually resolving merges with unnecessary conflicts.
    1.33 +Subversion also fails to merge changes when files or directories are
    1.34 +renamed.  Subversion's poor merge support is its single biggest
    1.35 +weakness.
    1.36  
    1.37  Mercurial has a substantial performance advantage over Subversion on
    1.38  every revision control operation I have benchmarked.  I have measured
    1.39 @@ -385,24 +389,44 @@
    1.40  involving a network-based store, Subversion will be at a substantially
    1.41  larger disadvantage.  Because many Subversion commands must talk to
    1.42  the server and Subversion does not have useful replication facilities,
    1.43 -server capacity becomes a bottleneck for modestly large projects.
    1.44 -
    1.45 -Additionally, Subversion incurs a substantial storage overhead to
    1.46 -avoid network transactions for a few common operations, such as
    1.47 -finding modified files (\texttt{status}) and displaying modifications
    1.48 -against the current revision (\texttt{diff}).  A Subversion working
    1.49 -copy is, as a result, often approximately the same size as, or larger
    1.50 -than, a Mercurial repository and working directory, even though the
    1.51 -Mercurial repository contains a complete history of the project.
    1.52 -
    1.53 -Subversion is currently more widely supported by
    1.54 -revision-control-aware third party tools than is Mercurial, although
    1.55 -this gap is closing.  Like Mercurial, Subversion has an excellent user
    1.56 -manual.
    1.57 -
    1.58 -Several tools exist to accurately and completely import revision
    1.59 -history from a Subversion repository into a Mercurial repository,
    1.60 -making the transition from the older tool relatively painless.
    1.61 +server capacity and network bandwidth become bottlenecks for modestly
    1.62 +large projects.
    1.63 +
    1.64 +Additionally, Subversion incurs substantial storage overhead to avoid
    1.65 +network transactions for a few common operations, such as finding
    1.66 +modified files (\texttt{status}) and displaying modifications against
    1.67 +the current revision (\texttt{diff}).  As a result, a Subversion
    1.68 +working copy is often the same size as, or larger than, a Mercurial
    1.69 +repository and working directory, even though the Mercurial repository
    1.70 +contains a complete history of the project.
    1.71 +
    1.72 +Subversion is widely supported by third party tools.  Mercurial
    1.73 +currently lags considerably in this area.  This gap is closing,
    1.74 +however, and indeed some of Mercurial's GUI tools now outshine their
    1.75 +Subversion equivalents.  Like Mercurial, Subversion has an excellent
    1.76 +user manual.
    1.77 +
    1.78 +Because Subversion doesn't store revision history on the client, it is
    1.79 +well suited to managing projects that deal with lots of large, opaque
    1.80 +binary files.  If you check in fifty revisions to an incompressible
    1.81 +10MB file, Subversion's client-side space usage stays constant The
    1.82 +space used by any distributed SCM will grow rapidly in proportion to
    1.83 +the number of revisions, because the differences between each revision
    1.84 +are large.
    1.85 +
    1.86 +In addition, it's often difficult or, more usually, impossible to
    1.87 +merge different versions of a binary file.  Subversion's ability to
    1.88 +let a user lock a file, so that they temporarily have the exclusive
    1.89 +right to commit changes to it, can be a significant advantage to a
    1.90 +project where binary files are widely used.
    1.91 +
    1.92 +Mercurial can import revision history from a Subversion repository.
    1.93 +It can also export revision history to a Subversion repository.  This
    1.94 +makes it easy to ``test the waters'' and use Mercurial and Subversion
    1.95 +in parallel before deciding to switch.  History conversion is
    1.96 +incremental, so you can perform an initial conversion, then small
    1.97 +additional conversions afterwards to bring in new changes.
    1.98 +
    1.99  
   1.100  \subsection{Git}
   1.101  
   1.102 @@ -410,15 +434,16 @@
   1.103  managing the Linux kernel source tree.  Like Mercurial, its early
   1.104  design was somewhat influenced by Monotone.
   1.105  
   1.106 -Git has an overwhelming command set, with version~1.5.0 providing~139
   1.107 -individual commands.  It has a reputation for being difficult to
   1.108 -learn.  It does not have a user manual, only documentation for
   1.109 -individual commands.
   1.110 -
   1.111 -In terms of performance, git is extremely fast.  There are several
   1.112 -common cases in which it is faster than Mercurial, at least on Linux.
   1.113 -However, its performance on (and general support for) Windows is, at
   1.114 -the time of writing, far behind that of Mercurial.
   1.115 +Git has a very large command set, with version~1.5.0 providing~139
   1.116 +individual commands.  It has something of a reputation for being
   1.117 +difficult to learn.  Compared to Git, Mercurial has a strong focus on
   1.118 +simplicity.
   1.119 +
   1.120 +In terms of performance, Git is extremely fast.  In several cases, it
   1.121 +is faster than Mercurial, at least on Linux, while Mercurial performs
   1.122 +better on other operations.  However, on Windows, the performance and
   1.123 +general level of support that Git provides is, at the time of writing,
   1.124 +far behind that of Mercurial.
   1.125  
   1.126  While a Mercurial repository needs no maintenance, a Git repository
   1.127  requires frequent manual ``repacks'' of its metadata.  Without these,
   1.128 @@ -432,14 +457,17 @@
   1.129  
   1.130  The core of Git is written in C.  Many Git commands are implemented as
   1.131  shell or Perl scripts, and the quality of these scripts varies widely.
   1.132 -I have encountered a number of instances where scripts charged along
   1.133 +I have encountered several instances where scripts charged along
   1.134  blindly in the presence of errors that should have been fatal.
   1.135  
   1.136 +Mercurial can import revision history from a Git repository.
   1.137 +
   1.138 +
   1.139  \subsection{CVS}
   1.140  
   1.141  CVS is probably the most widely used revision control tool in the
   1.142 -world.  Due to its age and internal untidiness, it has been
   1.143 -essentially unmaintained for many years.
   1.144 +world.  Due to its age and internal untidiness, it has been only
   1.145 +lightly maintained for many years.
   1.146  
   1.147  It has a centralised client/server architecture.  It does not group
   1.148  related file changes into atomic commits, making it easy for people to
   1.149 @@ -470,6 +498,9 @@
   1.150  remained locked for over a decade are just two of the less interesting
   1.151  problems I can recall from personal experience).
   1.152  
   1.153 +Mercurial can import revision history from a CVS repository.
   1.154 +
   1.155 +
   1.156  \subsection{Commercial tools}
   1.157  
   1.158  Perforce has a centralised client/server architecture, with no
   1.159 @@ -482,6 +513,54 @@
   1.160  Modestly large Perforce installations require the deployment of
   1.161  proxies to cope with the load their users generate.
   1.162  
   1.163 +
   1.164 +\subsection{Choosing a revision control tool}
   1.165 +
   1.166 +With the exception of CVS, all of the tools listed above have unique
   1.167 +strengths that suit them to particular styles of work.  There is no
   1.168 +single revision control tool that is best in all situations.
   1.169 +
   1.170 +As an example, Subversion is a good choice for working with frequently
   1.171 +edited binary files, due to its centralised nature and support for
   1.172 +file locking.  If you're averse to the command line, it currently has
   1.173 +better GUI support than other free revision control tools.  However,
   1.174 +its poor merging is a substantial liability for busy projects with
   1.175 +overlapping development.
   1.176 +
   1.177 +I personally find Mercurial's properties of simplicity, performance,
   1.178 +and good merge support to be a compelling combination that has served
   1.179 +me well for several years.
   1.180 +
   1.181 +
   1.182 +\section{Switching from another tool to Mercurial}
   1.183 +
   1.184 +Mercurial is bundled with an extension named \hgext{convert}, which
   1.185 +can incrementally import revision history from several other revision
   1.186 +control tools.  By ``incremental'', I mean that you can convert all of
   1.187 +a project's history to date in one go, then rerun the conversion later
   1.188 +to obtain new changes that happened after the initial conversion.
   1.189 +
   1.190 +The revision control tools supported by \hgext{convert} are as
   1.191 +follows:
   1.192 +\begin{itemize}
   1.193 +\item Subversion
   1.194 +\item CVS
   1.195 +\item Git
   1.196 +\item Darcs
   1.197 +\end{itemize}
   1.198 +
   1.199 +In addition, \hgext{convert} can export changes from Mercurial to
   1.200 +Subversion.  This makes it possible to try Subversion and Mercurial in
   1.201 +parallel before committing to a switchover, without risking the loss
   1.202 +of any work.
   1.203 +
   1.204 +The \hgxcmd{conver}{convert} command is easy to use.  Simply point it
   1.205 +at the path or URL of the source repository, optionally give it the
   1.206 +name of the destination repository, and it will start working.  After
   1.207 +the initial conversion, just run the same command again to import new
   1.208 +changes.
   1.209 +
   1.210 +
   1.211  %%% Local Variables: 
   1.212  %%% mode: latex
   1.213  %%% TeX-master: "00book"