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