1. Bryan O'Sullivan
  2. hgbook


Bryan O'Sullivan  committed 0b97b0b

Basic merge coverage.

  • Participants
  • Parent commits 97638d8
  • Branches default

Comments (0)

Files changed (2)

File en/examples/tour

View file
  • Ignore whitespace
 hg update 2
 hg parents
+hg update
 #$ name: clone-push
 hg push http://hg.serpentine.com/tutorial/hello
-#$ name:
-exit 0
+#$ name: merge.clone
+cd ..
+hg clone hello my-new-hello
+cd my-new-hello
+sed -i '/printf/i\\tprintf("once more, hello.\\n");' hello.c
+hg commit -m 'A new hello for a new day.'
+#$ name: merge.cat
+cat hello.c
+cat ../my-hello/hello.c
+#$ name: merge.pull
+hg pull ../my-hello
+#$ name: merge.heads
+hg heads
+#$ name: merge.update
+hg update
+#$ name: merge.merge
+hg merge
+#$ name: merge.parents
+hg parents
+cat hello.c
+#$ name: merge.commit
+hg commit -m 'Merged changes'
+#$ name: merge.tip
+hg tip

File en/tour.tex

View file
  • Ignore whitespace
 revision number or changeset~ID to the \hgcmd{update} command.
 If you omit an explicit revision, \hgcmd{update} will update to the
-tip revision.
+tip revision, as shown by the second call to \hgcmd{update} in the
+example above.
 \subsection{Pushing changes to another repository}
 anonymous users push to it.
+\section{Merging streams of work}
+We've now covered cloning a repository, making changes in a
+repository, and pulling or pushing changes from one repository into
+another.  Our next step is \emph{merging} changes from separate
+Merging is a fundamental part of working with a distributed revision
+control tool.
+\item Alice and Bob each have a personal copy of a repository for a
+  project they're collaborating on.  Alice fixes a bug in her
+  repository; Bob adds a new feature in his.  They want the shared
+  repository to contain both the bug fix and the new feature.
+\item I frequently work on several different tasks for a single
+  project at once, each safely isolated in its own repository.
+  Working this way means that I often need to merge one piece of my
+  own work with another.
+Because merging is such a common thing to need to do, Mercurial makes
+it easy.  Let's walk through the process.  We'll begin by cloning yet
+another repository (see how often they spring up?) and making a change
+in it.
+We should now have two copies of \filename{hello.c} with different
+We already know that pulling changes from our \dirname{my-hello}
+repository will have no effect on the working directory.
+However, the \hgcmd{pull} command says something about ``heads''.  
+A head is a change that has no descendants.  The tip revision is thus
+a head, but a repository can contain more than one head.  We can view
+them using the \hgcmd{heads} command.
+What happens if we try to use the normal \hgcmd{update} command to
+update to the new tip?
+Mercurial is telling us that the \hgcmd{update} command won't do a
+merge.  Instead, we use the \hgcmd{merge} command to merge the two
+This updates the working directory so that it contains changes from
+both heads, which is reflected in both the output of \hgcmd{parents}
+and the contents of \filename{hello.c}.
+Whenever we've done a merge, \hgcmd{parents} will display two parents
+until we \hgcmd{commit} the results of the merge.
+We now have a new tip revision; notice that it has \emph{both} of
+our former heads as its parents.  These are the same revisions that
+were previously displayed by \hgcmd{parents}.
 %%% Local Variables: 
 %%% mode: latex
 %%% TeX-master: "00book"