1.1 --- a/en/intro.tex	Tue May 15 13:43:17 2007 -0700
     1.2 +++ b/en/intro.tex	Sun Jun 03 09:49:14 2007 -0700
     1.3 @@ -372,13 +372,20 @@
     1.4  one to learn to use the other.  Both tools are portable to all popular
     1.5  operating systems.
     1.6  
     1.7 +Subversion lacks a history-aware merge capability, forcing its users
     1.8 +to manually track exactly which revisions have been merged between
     1.9 +branches.  If users fail to do this, or make mistakes, they face the
    1.10 +prospect of manually resolving merges with unnecessary conflicts.
    1.11 +
    1.12  Mercurial has a substantial performance advantage over Subversion on
    1.13  every revision control operation I have benchmarked.  I have measured
    1.14  its advantage as ranging from a factor of two to a factor of six when
    1.15  compared with Subversion~1.4.3's \emph{ra\_local} file store, which is
    1.16  the fastest access method available).  In more realistic deployments
    1.17  involving a network-based store, Subversion will be at a substantially
    1.18 -larger disadvantage.
    1.19 +larger disadvantage.  Because many Subversion commands must talk to
    1.20 +the server and Subversion does not have useful replication facilities,
    1.21 +server capacity becomes a bottleneck for modestly large projects.
    1.22  
    1.23  Additionally, Subversion incurs a substantial storage overhead to
    1.24  avoid network transactions for a few common operations, such as
    1.25 @@ -388,10 +395,6 @@
    1.26  than, a Mercurial repository and working directory, even though the
    1.27  Mercurial repository contains a complete history of the project.
    1.28  
    1.29 -Subversion does not have a history-aware merge capability, forcing its
    1.30 -users to know exactly which revisions to merge between branches.  This
    1.31 -shortcoming is scheduled to be addressed in version 1.5.
    1.32 -
    1.33  Subversion is currently more widely supported by
    1.34  revision-control-aware third party tools than is Mercurial, although
    1.35  this gap is closing.  Like Mercurial, Subversion has an excellent user
    1.36 @@ -440,13 +443,20 @@
    1.37  
    1.38  It has a centralised client/server architecture.  It does not group
    1.39  related file changes into atomic commits, making it easy for people to
    1.40 -``break the build''.  It has a muddled and incoherent notion of tags
    1.41 -and branches that I will not attempt to even describe.  It does not
    1.42 -support renaming of files or directories well, making it easy to
    1.43 -corrupt a repository.  It has almost no internal consistency checking
    1.44 -capabilities, so it is usually not even possible to tell whether or
    1.45 -how a repository is corrupt.  I would not recommend CVS for any
    1.46 -project, existing or new.
    1.47 +``break the build'': one person can successfully commit part of a
    1.48 +change and then be blocked by the need for a merge, causing other
    1.49 +people to see only a portion of the work they intended to do.  This
    1.50 +also affects how you work with project history.  If you want to see
    1.51 +all of the modifications someone made as part of a task, you will need
    1.52 +to manually inspect the descriptions and timestamps of the changes
    1.53 +made to each file involved (if you even know what those files were).
    1.54 +
    1.55 +CVS has a muddled notion of tags and branches that I will not attempt
    1.56 +to even describe.  It does not support renaming of files or
    1.57 +directories well, making it easy to corrupt a repository.  It has
    1.58 +almost no internal consistency checking capabilities, so it is usually
    1.59 +not even possible to tell whether or how a repository is corrupt.  I
    1.60 +would not recommend CVS for any project, existing or new.
    1.61  
    1.62  Mercurial can import CVS revision history.  However, there are a few
    1.63  caveats that apply; these are true of every other revision control