1.1 --- a/en/tour.tex	Thu Oct 12 16:27:00 2006 -0700
     1.2 +++ b/en/tour.tex	Fri Oct 13 13:55:06 2006 -0700
     1.3 @@ -477,7 +477,8 @@
     1.4  revision number or changeset~ID to the \hgcmd{update} command.
     1.5  \interaction{tour.older}
     1.6  If you omit an explicit revision, \hgcmd{update} will update to the
     1.7 -tip revision.
     1.8 +tip revision, as shown by the second call to \hgcmd{update} in the
     1.9 +example above.
    1.10  
    1.11  \subsection{Pushing changes to another repository}
    1.12  
    1.13 @@ -512,6 +513,63 @@
    1.14  anonymous users push to it.
    1.15  \interaction{tour.push.net}
    1.16  
    1.17 +\section{Merging streams of work}
    1.18 +
    1.19 +We've now covered cloning a repository, making changes in a
    1.20 +repository, and pulling or pushing changes from one repository into
    1.21 +another.  Our next step is \emph{merging} changes from separate
    1.22 +repositories.
    1.23 +
    1.24 +Merging is a fundamental part of working with a distributed revision
    1.25 +control tool.
    1.26 +\begin{itemize}
    1.27 +\item Alice and Bob each have a personal copy of a repository for a
    1.28 +  project they're collaborating on.  Alice fixes a bug in her
    1.29 +  repository; Bob adds a new feature in his.  They want the shared
    1.30 +  repository to contain both the bug fix and the new feature.
    1.31 +\item I frequently work on several different tasks for a single
    1.32 +  project at once, each safely isolated in its own repository.
    1.33 +  Working this way means that I often need to merge one piece of my
    1.34 +  own work with another.
    1.35 +\end{itemize}
    1.36 +
    1.37 +Because merging is such a common thing to need to do, Mercurial makes
    1.38 +it easy.  Let's walk through the process.  We'll begin by cloning yet
    1.39 +another repository (see how often they spring up?) and making a change
    1.40 +in it.
    1.41 +\interaction{tour.merge.clone}
    1.42 +We should now have two copies of \filename{hello.c} with different
    1.43 +contents.
    1.44 +\interaction{tour.merge.cat}
    1.45 +
    1.46 +We already know that pulling changes from our \dirname{my-hello}
    1.47 +repository will have no effect on the working directory.
    1.48 +\interaction{tour.merge.pull}
    1.49 +However, the \hgcmd{pull} command says something about ``heads''.  
    1.50 +
    1.51 +A head is a change that has no descendants.  The tip revision is thus
    1.52 +a head, but a repository can contain more than one head.  We can view
    1.53 +them using the \hgcmd{heads} command.
    1.54 +\interaction{tour.merge.heads}
    1.55 +What happens if we try to use the normal \hgcmd{update} command to
    1.56 +update to the new tip?
    1.57 +\interaction{tour.merge.update}
    1.58 +Mercurial is telling us that the \hgcmd{update} command won't do a
    1.59 +merge.  Instead, we use the \hgcmd{merge} command to merge the two
    1.60 +heads.
    1.61 +\interaction{tour.merge.merge}
    1.62 +This updates the working directory so that it contains changes from
    1.63 +both heads, which is reflected in both the output of \hgcmd{parents}
    1.64 +and the contents of \filename{hello.c}.
    1.65 +\interaction{tour.merge.parents}
    1.66 +Whenever we've done a merge, \hgcmd{parents} will display two parents
    1.67 +until we \hgcmd{commit} the results of the merge.
    1.68 +\interaction{tour.merge.commit}
    1.69 +We now have a new tip revision; notice that it has \emph{both} of
    1.70 +our former heads as its parents.  These are the same revisions that
    1.71 +were previously displayed by \hgcmd{parents}.
    1.72 +\interaction{tour.merge.tip}
    1.73 +
    1.74  %%% Local Variables: 
    1.75  %%% mode: latex
    1.76  %%% TeX-master: "00book"