1.1 --- a/en/intro.tex	Mon May 14 11:20:34 2007 -0700
     1.2 +++ b/en/intro.tex	Mon May 14 15:22:32 2007 -0700
     1.3 @@ -226,6 +226,8 @@
     1.4  something that is relatively rare compared with local operations.  If
     1.5  you have a far-flung team of collaborators, this may be significant.
     1.6  
     1.7 +\subsection{Advantages for open source projects}
     1.8 +
     1.9  If you take a shine to an open source project and decide that you
    1.10  would like to start hacking on it, and that project uses a distributed
    1.11  revision control tool, you are at once a peer with the people who
    1.12 @@ -239,13 +241,82 @@
    1.13  be at risk of corruption any time you try to update your client's view
    1.14  of the repository.
    1.15  
    1.16 -\subsection{For open source projects}
    1.17 -
    1.18 -\subsection{For commercial projects}
    1.19 -
    1.20 -\subsection{Myths about distributed revision control}
    1.21 -
    1.22 -\subsubsection{Distributed tools encourage projects to fork}
    1.23 +\subsubsection{The forking non-problem}
    1.24 +
    1.25 +It has been suggested that distributed revision control tools pose
    1.26 +some sort of risk to open source projects because they make it easy to
    1.27 +``fork'' the development of a project.  A fork happens when there are
    1.28 +differences in opinion or attitude between groups of developers that
    1.29 +cause them to decide that they can't work together any longer.  Each
    1.30 +side takes a more or less complete copy of the project's source code,
    1.31 +and goes off in its own direction.
    1.32 +
    1.33 +Sometimes the camps in a fork decide to reconcile their differences.
    1.34 +With a centralised revision control system, the \emph{technical}
    1.35 +process of reconciliation is painful, and has to be performed largely
    1.36 +by hand.  You have to decide whose revision history is going to
    1.37 +``win'', and graft the other team's changes into the tree somehow.
    1.38 +This usually loses some or all of one side's revision history.
    1.39 +
    1.40 +What distributed tools do with respect to forking is they make forking
    1.41 +the \emph{only} way to develop a project.  Every single change that
    1.42 +you make is potentially a fork point.  The great strength of this
    1.43 +approach is that a distributed revision control tool has to be really
    1.44 +good at \emph{merging} forks, because forks are absolutely
    1.45 +fundamental: they happen all the time.  
    1.46 +
    1.47 +If every piece of work that everybody does, all the time, is framed in
    1.48 +terms of forking and merging, then what the open source world refers
    1.49 +to as a ``fork'' becomes \emph{purely} a social issue.  If anything,
    1.50 +distributed tools \emph{lower} the likelihood of a fork:
    1.51 +\begin{itemize}
    1.52 +\item They eliminate the social distinction that centralised tools
    1.53 +  impose: that between insiders (people with commit access) and
    1.54 +  outsiders (people without).
    1.55 +\item They make it easier to reconcile after a social fork, because
    1.56 +  all that's involved from the perspective of the revision control
    1.57 +  software is just another merge.
    1.58 +\end{itemize}
    1.59 +
    1.60 +Some people resist distributed tools because they want to retain tight
    1.61 +control over their projects, and they believe that centralised tools
    1.62 +give them this control.  However, if you're of this belief, and you
    1.63 +publish your CVS or Subversion repositories publically, there are
    1.64 +plenty of tools available that can pull out your entire project's
    1.65 +history (albeit slowly) and recreate it somewhere that you don't
    1.66 +control.  So while your control in this case is illusory, you are
    1.67 +foregoing the ability to fluidly collaborate with whatever people feel
    1.68 +compelled to mirror and fork your history.
    1.69 +
    1.70 +\subsection{Advantages for commercial projects}
    1.71 +
    1.72 +Many commercial projects are undertaken by teams that are scattered
    1.73 +across the globe.  Contributors who are far from a central server will
    1.74 +see slower command execution and perhaps less reliability.  Commercial
    1.75 +revision control systems attempt to ameliorate these problems with
    1.76 +remote-site replication add-ons that are typically expensive to buy
    1.77 +and cantankerous to administer.  A distributed system doesn't suffer
    1.78 +from these problems in the first place.  Better yet, you can easily
    1.79 +set up multiple authoritative servers, say one per site, so that
    1.80 +there's no redundant communication between repositories over expensive
    1.81 +long-haul network links.
    1.82 +
    1.83 +Centralised revision control systems tend to have relatively low
    1.84 +scalability.  It's not unusual for an expensive centralised system to
    1.85 +fall over under the combined load of just a few dozen concurrent
    1.86 +users.  Once again, the typical response tends to be an expensive and
    1.87 +clunky replication facility.  Since the load on a central server---if
    1.88 +you have one at all---is orders of magnitude lower with a distributed
    1.89 +tool (because all of the data is replicated everywhere), a single
    1.90 +cheap server can handle the needs of a much larger team, and
    1.91 +replication to balance load becomes a simple matter of scripting.
    1.92 +
    1.93 +If you have an employee in the field, troubleshooting a problem at a
    1.94 +customer's site, they'll benefit from distributed revision control.
    1.95 +The tool will let them generate custom builds, try different fixes in
    1.96 +isolation from each other, and search efficiently through history for
    1.97 +the sources of bugs and regressions in the customer's environment, all
    1.98 +without needing to connect to your company's network.
    1.99  
   1.100  \section{Why choose Mercurial?}
   1.101