| rev |
line source |
|
bos@95
|
1 \chapter{A tour of Mercurial: merging work}
|
|
bos@95
|
2 \label{chap:tour-merge}
|
|
bos@94
|
3
|
|
bos@94
|
4 We've now covered cloning a repository, making changes in a
|
|
bos@94
|
5 repository, and pulling or pushing changes from one repository into
|
|
bos@94
|
6 another. Our next step is \emph{merging} changes from separate
|
|
bos@94
|
7 repositories.
|
|
bos@94
|
8
|
|
bos@95
|
9 \section{Merging streams of work}
|
|
bos@95
|
10
|
|
bos@94
|
11 Merging is a fundamental part of working with a distributed revision
|
|
bos@94
|
12 control tool.
|
|
bos@94
|
13 \begin{itemize}
|
|
bos@94
|
14 \item Alice and Bob each have a personal copy of a repository for a
|
|
bos@94
|
15 project they're collaborating on. Alice fixes a bug in her
|
|
bos@94
|
16 repository; Bob adds a new feature in his. They want the shared
|
|
bos@94
|
17 repository to contain both the bug fix and the new feature.
|
|
bos@94
|
18 \item I frequently work on several different tasks for a single
|
|
bos@94
|
19 project at once, each safely isolated in its own repository.
|
|
bos@94
|
20 Working this way means that I often need to merge one piece of my
|
|
bos@94
|
21 own work with another.
|
|
bos@94
|
22 \end{itemize}
|
|
bos@94
|
23
|
|
bos@94
|
24 Because merging is such a common thing to need to do, Mercurial makes
|
|
bos@94
|
25 it easy. Let's walk through the process. We'll begin by cloning yet
|
|
bos@94
|
26 another repository (see how often they spring up?) and making a change
|
|
bos@94
|
27 in it.
|
|
bos@94
|
28 \interaction{tour.merge.clone}
|
|
bos@94
|
29 We should now have two copies of \filename{hello.c} with different
|
|
bos@94
|
30 contents.
|
|
bos@94
|
31 \interaction{tour.merge.cat}
|
|
bos@94
|
32
|
|
bos@94
|
33 We already know that pulling changes from our \dirname{my-hello}
|
|
bos@94
|
34 repository will have no effect on the working directory.
|
|
bos@94
|
35 \interaction{tour.merge.pull}
|
|
bos@94
|
36 However, the \hgcmd{pull} command says something about ``heads''.
|
|
bos@94
|
37
|
|
bos@94
|
38 A head is a change that has no descendants. The tip revision is thus
|
|
bos@94
|
39 a head, but a repository can contain more than one head. We can view
|
|
bos@94
|
40 them using the \hgcmd{heads} command.
|
|
bos@94
|
41 \interaction{tour.merge.heads}
|
|
bos@94
|
42 What happens if we try to use the normal \hgcmd{update} command to
|
|
bos@94
|
43 update to the new tip?
|
|
bos@94
|
44 \interaction{tour.merge.update}
|
|
bos@94
|
45 Mercurial is telling us that the \hgcmd{update} command won't do a
|
|
bos@94
|
46 merge. Instead, we use the \hgcmd{merge} command to merge the two
|
|
bos@94
|
47 heads.
|
|
bos@94
|
48 \interaction{tour.merge.merge}
|
|
bos@94
|
49 This updates the working directory so that it contains changes from
|
|
bos@94
|
50 both heads, which is reflected in both the output of \hgcmd{parents}
|
|
bos@94
|
51 and the contents of \filename{hello.c}.
|
|
bos@94
|
52 \interaction{tour.merge.parents}
|
|
bos@94
|
53 Whenever we've done a merge, \hgcmd{parents} will display two parents
|
|
bos@94
|
54 until we \hgcmd{commit} the results of the merge.
|
|
bos@94
|
55 \interaction{tour.merge.commit}
|
|
bos@94
|
56 We now have a new tip revision; notice that it has \emph{both} of
|
|
bos@94
|
57 our former heads as its parents. These are the same revisions that
|
|
bos@94
|
58 were previously displayed by \hgcmd{parents}.
|
|
bos@94
|
59 \interaction{tour.merge.tip}
|
|
bos@94
|
60
|
|
bos@84
|
61 %%% Local Variables:
|
|
bos@84
|
62 %%% mode: latex
|
|
bos@84
|
63 %%% TeX-master: "00book"
|
|
bos@84
|
64 %%% End:
|
