hgbook
diff en/tour.tex @ 94:0b97b0bdc830
Basic merge coverage.
author | Bryan O'Sullivan <bos@serpentine.com> |
---|---|
date | Fri Oct 13 13:55:06 2006 -0700 (2006-10-13) |
parents | 97638d862ef3 |
children |
line diff
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"