hgbook
diff en/tour-merge.tex @ 95:47ea206351d5
Split tour into two sections.
author | Bryan O'Sullivan <bos@serpentine.com> |
---|---|
date | Fri Oct 13 14:00:06 2006 -0700 (2006-10-13) |
parents | en/tour.tex@0b97b0bdc830 |
children | 06383f9e46e4 |
line diff
1.1 --- /dev/null Thu Jan 01 00:00:00 1970 +0000 1.2 +++ b/en/tour-merge.tex Fri Oct 13 14:00:06 2006 -0700 1.3 @@ -0,0 +1,64 @@ 1.4 +\chapter{A tour of Mercurial: merging work} 1.5 +\label{chap:tour-merge} 1.6 + 1.7 +We've now covered cloning a repository, making changes in a 1.8 +repository, and pulling or pushing changes from one repository into 1.9 +another. Our next step is \emph{merging} changes from separate 1.10 +repositories. 1.11 + 1.12 +\section{Merging streams of work} 1.13 + 1.14 +Merging is a fundamental part of working with a distributed revision 1.15 +control tool. 1.16 +\begin{itemize} 1.17 +\item Alice and Bob each have a personal copy of a repository for a 1.18 + project they're collaborating on. Alice fixes a bug in her 1.19 + repository; Bob adds a new feature in his. They want the shared 1.20 + repository to contain both the bug fix and the new feature. 1.21 +\item I frequently work on several different tasks for a single 1.22 + project at once, each safely isolated in its own repository. 1.23 + Working this way means that I often need to merge one piece of my 1.24 + own work with another. 1.25 +\end{itemize} 1.26 + 1.27 +Because merging is such a common thing to need to do, Mercurial makes 1.28 +it easy. Let's walk through the process. We'll begin by cloning yet 1.29 +another repository (see how often they spring up?) and making a change 1.30 +in it. 1.31 +\interaction{tour.merge.clone} 1.32 +We should now have two copies of \filename{hello.c} with different 1.33 +contents. 1.34 +\interaction{tour.merge.cat} 1.35 + 1.36 +We already know that pulling changes from our \dirname{my-hello} 1.37 +repository will have no effect on the working directory. 1.38 +\interaction{tour.merge.pull} 1.39 +However, the \hgcmd{pull} command says something about ``heads''. 1.40 + 1.41 +A head is a change that has no descendants. The tip revision is thus 1.42 +a head, but a repository can contain more than one head. We can view 1.43 +them using the \hgcmd{heads} command. 1.44 +\interaction{tour.merge.heads} 1.45 +What happens if we try to use the normal \hgcmd{update} command to 1.46 +update to the new tip? 1.47 +\interaction{tour.merge.update} 1.48 +Mercurial is telling us that the \hgcmd{update} command won't do a 1.49 +merge. Instead, we use the \hgcmd{merge} command to merge the two 1.50 +heads. 1.51 +\interaction{tour.merge.merge} 1.52 +This updates the working directory so that it contains changes from 1.53 +both heads, which is reflected in both the output of \hgcmd{parents} 1.54 +and the contents of \filename{hello.c}. 1.55 +\interaction{tour.merge.parents} 1.56 +Whenever we've done a merge, \hgcmd{parents} will display two parents 1.57 +until we \hgcmd{commit} the results of the merge. 1.58 +\interaction{tour.merge.commit} 1.59 +We now have a new tip revision; notice that it has \emph{both} of 1.60 +our former heads as its parents. These are the same revisions that 1.61 +were previously displayed by \hgcmd{parents}. 1.62 +\interaction{tour.merge.tip} 1.63 + 1.64 +%%% Local Variables: 1.65 +%%% mode: latex 1.66 +%%% TeX-master: "00book" 1.67 +%%% End: