Mercurial > hgbook
view ja/concepts.tex @ 799:7107b79427a3
Propagate 4e23c220d1b0
Update chapter 2
| author | Yoshiki Yazawa <yaz@honeyplanet.jp> |
|---|---|
| date | Thu, 18 Jun 2009 19:11:36 +0900 |
| parents | 43556decb81f |
| children | 1a30d2627512 |
line wrap: on
line source
%\chapter{Behind the scenes} \chapter{$BIqBfN"(B} \label{chap:concepts} %Unlike many revision control systems, the concepts upon which %Mercurial is built are simple enough that it's easy to understand how %the software really works. Knowing this certainly isn't necessary, %but I find it useful to have a ``mental model'' of what's going on. $BB?$/$N%j%S%8%g%s%3%s%H%m!<%k%7%9%F%`$H0c$C$F!$(B Mercurial$B$NF0:n$N4pK\$H$J$C(B $B$F$$$k%3%s%;%W%H$rM}2r$9$k$3$H$OMF0W$$!%(B $B$3$l$rM}2r$9$k$3$H$OI,$:$7$bI,MW$G$O$J$$$,!$I.<T$O!$2?$,5/$-$F$$$k$N$+$K(B $B$D$$$F%b%G%k$r0U<1$7$F$$$k$3$H$OM-MQ$G$"$k$H9M$($F$$$k!%(B %This understanding gives me confidence that Mercurial has been %carefully designed to be both \emph{safe} and \emph{efficient}. And %just as importantly, if it's easy for me to retain a good idea of what %the software is doing when I perform a revision control task, I'm less %likely to be surprised by its behaviour. $B$3$N$3$H$rM}2r$7$?8e$G!$I.<T$O(BMercurial$B$,(B\emph{$B0BA4(B}$B$H(B\emph{$B8zN((B}$B$r<B8=$9(B $B$k$h$&$KCm0U?<$/@_7W$5$l$F$$$k$H3N?.$9$k$K;j$C$?!%(B $B$^$?!$=EMW$JE@$H$7$F!$%j%S%8%g%s%3%s%H%m!<%k$NA`:n$r9T$&:]$K%=%U%H%&%'%"(B $B$,2?$r$9$k$N$+$r5-21$KN1$a$F$*$/$3$H$K$h$C$F!$IT0U$N5sF0$G6C$/$3$H$,>/$J(B $B$/$J$C$?!%(B %In this chapter, we'll initially cover the core concepts behind %Mercurial's design, then continue to discuss some of the interesting %details of its implementation. $B$3$N>O$G$O$^$:(BMercurial$B$N@_7W$N%3%"%3%s%;%W%H$r%+%P!<$9$k!%$=$7$F<BAu>e$N(B $B$$$/$D$+$N6=L#?<$$E@$N>\:Y$K$D$$$F5DO@$9$k!%(B %\section{Mercurial's historical record} \section{Mercurial$B$NMzNr5-O?(B} %\subsection{Tracking the history of a single file} \subsection{$B%U%!%$%kMzNr$NDI@W(B} %When Mercurial tracks modifications to a file, it stores the history %of that file in a metadata object called a \emph{filelog}. Each entry %in the filelog contains enough information to reconstruct one revision %of the file that is being tracked. Filelogs are stored as files in %the \sdirname{.hg/store/data} directory. A filelog contains two kinds %of information: revision data, and an index to help Mercurial to find %a revision efficiently. Mercurial$B$O%U%!%$%k$X$NJQ99$rDI@W$9$k;~!$%U%!%$%k$NMzNr$r(B\emph{filelog}$B$H(B $B8F$P$l$k%a%?%G!<%?%*%V%8%'%/%H$K3JG<$9$k!%%U%!%$%k%m%0Fb$N3F!9$N%(%s%H%j(B $B$O!$DI@WBP>]$N%U%!%$%k$N%j%S%8%g%s$r:F7z$9$k$N$K==J,$J>pJs$r;}$D!%%U%!%$(B $B%k%m%0$O(B\sdirname{.hg/store/data}$B%G%#%l%/%H%j$K%U%!%$%k$H$7$FJ]B8$5$l$k!%(B $B%U%!%$%k%m%0$O%j%S%8%g%s%G!<%?$H(BMercurial$B$,%j%S%8%g%s$r8zN(E*$K8+$D$1$i$l(B $B$k$h$&$K$9$k$?$a$N%$%s%G%C%/%9$N(B2$B<oN`$N>pJs$r;}$D!%(B %A file that is large, or has a lot of history, has its filelog stored %in separate data (``\texttt{.d}'' suffix) and index (``\texttt{.i}'' %suffix) files. For small files without much history, the revision %data and index are combined in a single ``\texttt{.i}'' file. The %correspondence between a file in the working directory and the filelog %that tracks its history in the repository is illustrated in %figure~\ref{fig:concepts:filelog}. $B%5%$%:$NBg$-$J%U%!%$%k$d!$KDBg$JMzNr$r;}$D%U%!%$%k$O!$%G!<%?$,(B (``\texttt{.d}'' suffix) $B$*$h$S%$%s%G%C%/%9(B (``\texttt{.i}'' suffix)$B$N%U%!(B $B%$%k$KJ,3d$5$l$?(Bfilelog$B$r;}$D!%%5%$%:$,>.$5$/!$MzNr$NBg$-$/$J$$%U%!%$%k$O(B $B%j%S%8%g%s%G!<%?$H%$%s%G%C%/%9$,(B1$B$D$N(B``\texttt{.i}''$B%U%!%$%k$K7k9g$5$l$F(B $B$$$k!%%o!<%-%s%0%G%#%l%/%H%jFb$N%U%!%$%k$H%j%]%8%H%jFb$NMzNr$rDI@W$9$k(B filelog$B$H$NBP1~$r?^(B~\ref{fig:concepts:filelog}$B$K<($9!%(B \begin{figure}[ht] \centering % \grafix{filelog} \includegraphics{filelog} % \caption{Relationships between files in working directory and % filelogs in repository} \caption{$B%o!<%-%s%0%G%#%l%/%H%jFb$N%U%!%$%k$H%j%]%8%H%j$N%U%!%$%k%m%0(B $B$N4X78(B} \label{fig:concepts:filelog} \end{figure} %\subsection{Managing tracked files} \subsection{$BDI@W$5$l$F$$$k%U%!%$%k$N4IM}(B} %Mercurial uses a structure called a \emph{manifest} to collect %together information about the files that it tracks. Each entry in %the manifest contains information about the files present in a single %changeset. An entry records which files are present in the changeset, %the revision of each file, and a few other pieces of file metadata. Mercurial$B$O(B\emph{$B%^%K%U%'%9%H(B}$B$H8F$P$l$k9=B$$rMQ$$$F!$DI@W$9$Y$-%U%!%$%k(B $B$N>pJs$r=8$a$F$$$k!%%^%K%U%'%9%HFb$N3F!9$N%(%s%H%j$O!$C10l$N%A%'%s%8%;%C(B $B%HFb$KB8:_$9$k%U%!%$%k$N>pJs$r;}$C$F$$$k!%%(%s%H%j$O$I$N%U%!%$%k$,%A%'%s(B $B%8%;%C%H$KB8:_$7$F$$$k$+!$$=$l$i$N%j%S%8%g%s$,2?$G$"$k$N$+$H$$$&>pJs$H!$(B $B$$$/$D$+$NB>$N%U%!%$%k%a%?%G!<%?$r5-O?$7$F$$$k!%(B %\subsection{Recording changeset information} \subsection{$B%A%'%s%8%;%C%H>pJs$N5-O?(B} %The \emph{changelog} contains information about each changeset. Each %revision records who committed a change, the changeset comment, other %pieces of changeset-related information, and the revision of the %manifest to use. \emph{changelog}$B$O3F!9$N%A%'%s%8%;%C%H$N>pJs$r;}$D!%3F!9$N%j%S%8%g%s5-O?(B $B$O!$C/$,JQ99$r%3%_%C%H$7$?$N$+!$%A%'%s%8%;%C%H$N%3%a%s%H!$JQ99$K4XO"$7$?(B $BB>$N>pJs!$;HMQ$5$l$k%^%K%U%'%9%H$N%j%S%8%g%s$r;}$D!%(B %\subsection{Relationships between revisions} \subsection{$B%j%S%8%g%s4V$N4X78(B} %Within a changelog, a manifest, or a filelog, each revision stores a %pointer to its immediate parent (or to its two parents, if it's a %merge revision). As I mentioned above, there are also relationships %between revisions \emph{across} these structures, and they are %hierarchical in nature. $B%A%'%s%8%m%0!$%^%K%U%'%9%H!$%U%!%$%k%m%0Fb$G!$3F!9$N%j%S%8%g%s$OD>@\$N?F(B $B!J$"$k$$$O%^!<%8$N>l9g$O$=$NN>?F!K$X$N%]%$%s%?$r;}$D!%(B $B$9$G$K=R$Y$?$h$&$K!$$3$N9=B$$K8=$l$k%j%S%8%g%s$N4V$K$O4X78$,$"$j!$K\<A(B $BE*$K3,AXE*$G$"$k!%(B %For every changeset in a repository, there is exactly one revision %stored in the changelog. Each revision of the changelog contains a %pointer to a single revision of the manifest. A revision of the %manifest stores a pointer to a single revision of each filelog tracked %when that changeset was created. These relationships are illustrated %in figure~\ref{fig:concepts:metadata}. $B%j%]%8%H%j$K$"$k$9$Y$F$N%A%'%s%8%;%C%H$O!$%A%'%s%8%m%0Fb$G@53N$K(B1$B$D$N%j%S(B $B%8%g%s$r;}$D!%%A%'%s%8%m%0$N3F!9$N%j%S%8%g%s$O!$%^%K%U%'%9%H$NC10l$N%P!<(B $B%8%g%s$X$N%]%$%s%?$r;}$D!%%^%K%U%'%9%H$N3F!9$N%j%S%8%g%s$O!$%A%'%s%8%;%C(B $B%H$,@8@.$5$l$?;~$N%U%!%$%k%m%0$N3F!9$NC10l%j%S%8%g%s$X$N%]%$%s%?$r;}$D!%(B $B$3$N4X78$r?^(B~\ref{fig:concepts:metadata}$B$K<($9!%(B \begin{figure}[ht] \centering \includegraphics{metadata} % \caption{Metadata relationships} \caption{$B%a%?%G!<%?$N4X78(B} \label{fig:concepts:metadata} \end{figure} %As the illustration shows, there is \emph{not} a ``one to one'' %relationship between revisions in the changelog, manifest, or filelog. %If the manifest hasn't changed between two changesets, the changelog %entries for those changesets will point to the same revision of the %manifest. If a file that Mercurial tracks hasn't changed between two %changesets, the entry for that file in the two revisions of the %manifest will point to the same revision of its filelog. $B%$%i%9%H$G<($5$l$F$$$k$h$&$K!$%j%S%8%g%s$H%A%'%s%8%m%0!$%^%K%U%'%9%H$^$?(B $B$O%U%!%$%k%m%0$N4V$K$O(B1$BBP#1$N4X78$O$J$$!%%^%K%U%'%9%H$,(B2$B$D$N%A%'%s%8%;%C(B $B%H$N4V$GJQ2=$7$J$+$C$?>l9g$O!$%A%'%s%8%m%0Fb$G$3$l$i$N%A%'%s%8%;%C%H$rI=(B $B$9%(%s%H%j$OF1$8%P!<%8%g%s$N%^%K%U%'%9%H$r<($9!%(BMercurial$B$,DI@W$9$k%U%!%$(B $B%k$,!$(B2$B$D$N%A%'%s%8%;%C%H4V$GJQ2=$7$J$+$C$?>l9g$O!$(B 2$B$D$N%^%K%U%'%9%H$N%j(B $B%S%8%g%s$G!$$=$N%U%!%$%k$r<($9%(%s%H%j$O%U%!%$%k%m%0$NF1$8%j%S%8%g%s$r<((B $B$9!%(B %\section{Safe, efficient storage} \section{$B0BA4$+$D8zN(E*$J%9%H%l!<%8(B} %The underpinnings of changelogs, manifests, and filelogs are provided %by a single structure called the \emph{revlog}. $B%A%'%s%8%m%0!$%^%K%U%'%9%H$*$h$S%U%!%$%k%m%0$NEZBf$K;H$o$l$F$$$k$O6&DL$N(B \emph{revlog}$B$H$$$&9=B$BN$G$"$k!%(B %\subsection{Efficient storage} \subsection{$B8zN(E*$J%9%H%l!<%8(B} %The revlog provides efficient storage of revisions using a %\emph{delta} mechanism. Instead of storing a complete copy of a file %for each revision, it stores the changes needed to transform an older %revision into the new revision. For many kinds of file data, these %deltas are typically a fraction of a percent of the size of a full %copy of a file. revlog$B$O(B\emph{delta}$B5!9=$r;H$C$F%j%S%8%g%s$N8zN(E*$J5-21$rDs6!$9$k!%%U%!(B $B%$%k$N3F!9$N%P!<%8%g%s$N40A4$J%3%T!<$rJ]B8$9$k$N$G$O$J$/!$8E$$%j%S%8%g%s(B $B$r?7$7$$%P!<%8%g%s$XJQ49$9$k$N$KI,MW$JJQ99$rJ]B8$9$k!%B?$/$N%U%!%$%k%G!<(B $B%?$KBP$7$F!$(B delta$B$OE57?E*$K$O%U%!%$%k$N%U%k%3%T!<$N(B1$B%Q!<%;%s%HL$K~$G$"$"(B $B$k!%(B %Some obsolete revision control systems can only work with deltas of %text files. They must either store binary files as complete snapshots %or encoded into a text representation, both of which are wasteful %approaches. Mercurial can efficiently handle deltas of files with %arbitrary binary contents; it doesn't need to treat text as special. $B8E$$%j%S%8%g%s%3%s%H%m!<%k%7%9%F%`$N$$$/$D$+$O%F%-%9%H%U%!%$%k$N(Bdelta$B$KBP(B $B$7$F$7$+5!G=$7$J$$!%$=$l$i$N%7%9%F%`$G$O%P%$%J%j%U%!%$%k$O40A4$J%9%J%C%W(B $B%7%g%C%H$+!$%F%-%9%HI=8=$K%(%s%3!<%I$5$l$?7A<0$G$"$kI,MW$,$"$k!%$3$l$i$O(B $B6&$KL5BL$NB?$$%"%W%m!<%A$G$"$k!%(B Mercurial$B$OG$0U$N%P%$%J%j%U%!%$%k$K$D$$(B $B$F!$(Bdelta$B$r8zN(E*$K07$&$3$H$,$G$-!$%F%-%9%H$rFCJL07$$$9$kI,MW$,$J$$!%(B %\subsection{Safe operation} \subsection{$B0BA4$JF0:n(B} \label{sec:concepts:txn} %Mercurial only ever \emph{appends} data to the end of a revlog file. %It never modifies a section of a file after it has written it. This %is both more robust and efficient than schemes that need to modify or %rewrite data. Mercurial$B$O(Brevlog$B%U%!%$%k$NKvHx$K%G!<%?$N(B\emph{$BDI2C(B}$B$N$_$r9T$&!%0lEY=q$-(B $B9~$^$l$?ItJ,$O8e$K$J$C$FJQ99$5$l$k$3$H$O$J$$!%$3$l$O%G!<%?$NJQ99$d:F=q$-(B $B9~$_$r9T$&J}K!$h$j$b4h6/$+$D8zN(E*$G$"$k!%(B %In addition, Mercurial treats every write as part of a %\emph{transaction} that can span a number of files. A transaction is %\emph{atomic}: either the entire transaction succeeds and its effects %are all visible to readers in one go, or the whole thing is undone. %This guarantee of atomicity means that if you're running two copies of %Mercurial, where one is reading data and one is writing it, the reader %will never see a partially written result that might confuse it. $B2C$($F!$(BMercurial$B$O$"$i$f$k=q$-9~$_$rJ#?t$N%U%!%$%k$X$N(B\emph{$B%H%i%s%6%/%7%g(B $B%s(B}$B$N0lIt$H8+$J$9!%%H%i%s%6%/%7%g%sA4BN$,@.8y$7!$FI$_=P$7B&$K0lEY$K7k2L$,(B $B8+$($k>l9g$b!$$=$&$G$J$$>l9g$b%H%i%s%6%/%7%g%s$O(B\emph{$B%"%H%_%C%/(B}$B$G$"$k!%(B $B$3$N%"%H%_%C%/@-$NJ]>Z$O!$(B 2$B$D$N(BMercurial$B$r!$JRJ}$O%G!<%?$NFI$_=P$7!$$b$&(B $B0lJ}$O=q$-9~$_$G<B9T$7$F$$$k>l9g!$FI$_=P$7B&$K$O:.Mp$N860x$H$J$kItJ,E*$J(B $B=q$-9~$_7k2L$O8+$($J$$$3$H$r0UL#$9$k!%(B %The fact that Mercurial only appends to files makes it easier to %provide this transactional guarantee. The easier it is to do stuff %like this, the more confident you should be that it's done correctly. Mercurial$B$O%U%!%$%k$KDI5-$N$_$r$9$k$3$H$G!$%H%i%s%6%/%7%g%s$NJ]>Z$rMF0W$K(B $B$7$F$$$k!%J*;v$rC1=c2=$9$k$3$H$K$h$C$F!$=hM}$N@5$7$5$r3N<B$K$9$k$h$&$K$7(B $B$F$$$k!%(B %\subsection{Fast retrieval} \subsection{$B9bB.$J<hF@(B} %Mercurial cleverly avoids a pitfall common to all earlier %revision control systems: the problem of \emph{inefficient retrieval}. %Most revision control systems store the contents of a revision as an %incremental series of modifications against a ``snapshot''. To %reconstruct a specific revision, you must first read the snapshot, and %then every one of the revisions between the snapshot and your target %revision. The more history that a file accumulates, the more %revisions you must read, hence the longer it takes to reconstruct a %particular revision. Mercurial$B$O$3$l$^$G$N%j%S%8%g%s%3%s%H%m!<%k%7%9%F%`$K6&DL$7$?Mn$H$77j$r(B $B8-L@$KHr$1$F$$$k!%LdBj$@$C$?$N$O(B\emph{$BHs8zN(E*$J<hF@(B}$B$G$"$C$?!%(B $BBgDq$N%j%S%8%g%s%3%s%H%m!<%k%7%9%F%`$O%j%S%8%g%s$NFbMF$r%9%J%C%W%7%g%C%H(B $B$X$N0lO"$NJQ99$NA}J,$H$7$FJ]B8$7$F$$$k!%FCDj$N%j%S%8%g%s$r:F8=$9$k$?$a$K(B $B$O$^$:%9%J%C%W%7%g%C%H$rFI$_9~$_!$$7$+$k8e$KL\E*$N%j%S%8%g%s$rFI$`I,MW$,(B $B$"$C$?!%%U%!%$%k$X$NMzNr$,A}$($l$PA}$($k$[$IFI$_9~$^$J$1$l$P$J$i$J$$%j%S(B $B%8%g%s$,B?$/$J$j!$FCDj$N%j%S%8%g%s$r:F8=$9$k$N$K;~4V$,$+$+$k$h$&$K$J$k!%(B \begin{figure}[ht] \centering \includegraphics{snapshot} % \caption{Snapshot of a revlog, with incremental deltas} \caption{$B:9J,$rMQ$$$?(Brevlog$B$N%9%J%C%W%7%g%C%H(B} \label{fig:concepts:snapshot} \end{figure} %The innovation that Mercurial applies to this problem is simple but %effective. Once the cumulative amount of delta information stored %since the last snapshot exceeds a fixed threshold, it stores a new %snapshot (compressed, of course), instead of another delta. This %makes it possible to reconstruct \emph{any} revision of a file %quickly. This approach works so well that it has since been copied by %several other revision control systems. Mercurial$B$G$O$3$NLdBj$rC1=c$@$,8z2LE*$JJ}K!$G2r7h$7$F$$$k!%A02s$K%9%J%C%W(B $B%7%g%C%H$r:n@.$7$?;~E@$+$i$NN_@QE*$JA}J,$,0lDj$NogCM$r1[$($k$H!$?7$?$JA}(B $BJ,$G$O$J$/!$?7$?$J%9%J%C%W%7%g%C%H$,J]B8$5$l$k!J$3$N%9%J%C%W%7%g%C%H$OL^(B $BO@05=L$5$l$F$$$k!K!%$3$l$K$h$C$F(B\emph{$B$$$+$J$k(B}$B%j%S%8%g%s$b?WB.$K:F8=$5$l(B $B$k!%$3$N%"%W%m!<%A$O0J8eB>$N%j%S%8%g%s%3%s%H%m!<%k%7%9%F%`$K%3%T!<$5$l$k(B $B$[$I$&$^$/5!G=$7$F$$$k!%(B %Figure~\ref{fig:concepts:snapshot} illustrates the idea. In an entry %in a revlog's index file, Mercurial stores the range of entries from %the data file that it must read to reconstruct a particular revision. $B?^(B~\ref{fig:concepts:snapshot}$B$K35G0$r<($9!%(BMercurial$B$O(Brevlog$B$N%$%s%G%C%/(B $B%9%U%!%$%k$N%(%s%H%j$KFCDj$N%j%S%8%g%s$r:F8=$9$k$N$KI,MW$J%G!<%?%U%!%$%k(B $BFb$N$"$kHO0O$N%(%s%H%j$rJ]B8$9$k!%(B %\subsubsection{Aside: the influence of video compression} \subsubsection{$B$=$NB>(B: $B%S%G%*05=L$N1F6A(B} %If you're familiar with video compression or have ever watched a TV %feed through a digital cable or satellite service, you may know that %most video compression schemes store each frame of video as a delta %against its predecessor frame. In addition, these schemes use %``lossy'' compression techniques to increase the compression ratio, so %visual errors accumulate over the course of a number of inter-frame %deltas. $B%S%G%*05=L$K47$l$F$$$?$j!$%G%8%?%k$K$h$k%1!<%V%k$^$?$O1R@1J|Aw$K47$l$F$$(B $B$k$N$J$i!$BgItJ,$N%S%G%*05=L$N;EAH$_$G$O!$%S%G%*$N3F%U%l!<%`$,!$A0$N%U%l!<(B $B%`$H$N:9J,$H$7$FJ]B8$5$l$F$$$k$3$H$rCN$C$F$$$k$@$m$&!%2C$($F!$$3$l$i$N;E(B $BAH$_$O05=LN($r2T$0$?$a$KIT2D5U$J05=L5;=Q$r;H$C$F$*$j!$1GA|$N%(%i!<$O%U%l!<(B $B%`4V$N:9J,$,A}$($k$K=>$C$FC_@Q$7$F$$$/!%(B %Because it's possible for a video stream to ``drop out'' occasionally %due to signal glitches, and to limit the accumulation of artefacts %introduced by the lossy compression process, video encoders %periodically insert a complete frame (called a ``key frame'') into the %video stream; the next delta is generated against that frame. This %means that if the video signal gets interrupted, it will resume once %the next key frame is received. Also, the accumulation of encoding %errors restarts anew with each key frame. $B%S%G%*%9%H%j!<%`$G$O!$?.9f$NIT6q9g$K$h$C$F;~@^%I%m%C%W%"%&%H$,=P$k$3$H$,(B $B$"$j!$$^$?IT2D5U05=L$K$h$k1F6A$NC_@Q$rM^$($k$?$a!$%S%G%*%(%s%3!<%@$ODj4|(B $BE*$K!J%-!<%U%l!<%`$H8F$P$l$k!K40A4$J%U%l!<%`$r%9%H%j!<%`$KA^F~$9$k!%<!$N(B $B:9J,$O$3$N%U%l!<%`$KBP$7$F<h$i$l$k!%$3$l$K$h$C$F!$%S%G%*?.9f$,ES@d$($F$b(B $B<!$N%-!<%U%l!<%`$r<u?.$9$l$P@5>o$KLa$k$3$H$,$G$-$k!%$^$?%(%s%3!<%I%(%i!<(B $B$NC_@Q$O%-!<%U%l!<%`$4$H$K=|5n$5$l$k!%(B %\subsection{Identification and strong integrity} \subsection{$B<1JL$H6/$$0l4S@-(B} %Along with delta or snapshot information, a revlog entry contains a %cryptographic hash of the data that it represents. This makes it %difficult to forge the contents of a revision, and easy to detect %accidental corruption. $B:9J,$d%9%J%C%W%7%g%C%H>pJs$H6&$K!$(Brevlog$B%(%s%H%j$O%G!<%?$N0E9f%O%C%7%e(B $B$r;}$D!%%O%C%7%e$K$h$j!$%j%S%8%g%s$NFbMF$r56$k$3$H$,:$Fq$K$J$j!$$^$?(B $B;v8N$K$h$C$FFbMF$,GKB;$7$?>l9g!$H/8+$,MF0W$K$J$k!%(B %Hashes provide more than a mere check against corruption; they are %used as the identifiers for revisions. The changeset identification %hashes that you see as an end user are from revisions of the %changelog. Although filelogs and the manifest also use hashes, %Mercurial only uses these behind the scenes. $B%O%C%7%e$OC1$KGKB;$r%A%'%C%/$9$k0J>e$N$3$H$r9T$&!%$3$l$i$O%j%S%8%g%s$N<1(B $BJL$K$bMQ$$$i$l$k!%%A%'%s%8%;%C%H$N<1JL%O%C%7%e$O!$%(%s%I%f!<%6$+$i$O%A%'(B $B%s%8%m%0$G%f!<%6L>$H6&$K8=$l$k?t;z$H$7$FL\$K$9$k$3$H$,B?$$$@$m$&!%(B $B%U%!%$%k%m%0$H%^%K%U%'%9%H$G$b%O%C%7%e$O;H$o$l$F$$$k$,!$(BMercurial$B$O$3$l(B $B$i$rGX8e$G$N$_MQ$$$k!%(B %Mercurial verifies that hashes are correct when it retrieves file %revisions and when it pulls changes from another repository. If it %encounters an integrity problem, it will complain and stop whatever %it's doing. Mercurial$B$O%U%!%$%k$N%j%S%8%g%s<hF@;~$HJQ99$rJL$N%j%]%8%H%j$+$i(Bpull$B$9$k;~(B $B$K%O%C%7%e$,@5$7$$$3$H$r3NG'$9$k!%0l4S@-$KLdBj$,$"$k$H!$%(%i!<%a%C%;!<%8(B $B$r=PNO$7!$F0:n$rDd;_$9$k!%(B %In addition to the effect it has on retrieval efficiency, Mercurial's %use of periodic snapshots makes it more robust against partial data %corruption. If a revlog becomes partly corrupted due to a hardware %error or system bug, it's often possible to reconstruct some or most %revisions from the uncorrupted sections of the revlog, both before and %after the corrupted section. This would not be possible with a %delta-only storage model. $B<hF@$N8zN($K2C$($F!$(BMercurial$B$O<~4|E*$K%9%J%C%W%7%g%C%H$r;H$&$3$H$G!$ItJ,(B $BE*$J%G!<%?$NGKB;$KBP$7$F4h6/$K$J$C$F$$$k!%%O!<%I%&%'%"$NLdBj$d%7%9%F%`$N(B $B%P%0$G(Brevlog$B$,ItJ,E*$KGKB;$7$?>l9g$G$b!$B?$/$N>l9g!$(Brevlog$B$NGKB;$7$F$$$J(B $B$$ItJ,$+$iGKB;$7$?ItJ,$NA08e$G$$$/$D$+$N%j%S%8%g%s$dBgH>$N%j%S%8%g%s$r:F(B $B7z$9$k$3$H$,$G$-$k!%:9J,$N$_$r5-O?$9$k%7%9%F%`$G$O$3$l$r<B8=$9$k$3$H$O$G(B $B$-$J$$!%(B %\section{Revision history, branching, and merging} \section{$B%j%S%8%g%sMzNr!$%V%i%s%A!$%^!<%8(B} %Every entry in a Mercurial revlog knows the identity of its immediate %ancestor revision, usually referred to as its \emph{parent}. In fact, %a revision contains room for not one parent, but two. Mercurial uses %a special hash, called the ``null ID'', to represent the idea ``there %is no parent here''. This hash is simply a string of zeroes. Mercurial revlog$B$N$9$Y$F$N%(%s%H%j$O!$DL>o(B\emph{parent}$B$H$7$F;2>H$5$l$kD>(B $B@\$NAD@h$N%j%S%8%g%s$rCN$C$F$$$k!%<B:]$K$O!$%j%S%8%g%s$O(B1$B$D$@$1$G$J$/(B2$B$D(B $B$N?F$r5-O?$9$k$3$H$,$G$-$k!%(BMercurial$B$O(B``null ID''$B$H$$$&FCJL$J%O%C%7%e$r(B $B;H$C$F(B``$B$3$3$K$O?F$K$J$k%j%S%8%g%s$,$J$$(B''$B$H$$$&$3$H$rI=8=$9$k!%$3$N%O%C(B $B%7%e$OC1$K%<%m$rJB$Y$?J8;zNs$G$"$k!%(B %In figure~\ref{fig:concepts:revlog}, you can see an example of the %conceptual structure of a revlog. Filelogs, manifests, and changelogs %all have this same structure; they differ only in the kind of data %stored in each delta or snapshot. revlog$B$N35G0E*$J9=B$$N0lNc$r?^(B~\ref{fig:concepts:revlog}$B$K<($9!%%U%!%$%k(B $B%m%0!$%^%K%U%'%9%H$*$h$S%A%'%s%8%m%0$O$9$Y$FF1$89=B$$r;}$D!%$3$l$i$N0c$$(B $B$O!$3F!9$N:9J,$d%9%J%C%W%7%g%C%H$K3JG<$9$k%G!<%?$N0c$$$@$1$G$"$k!%(B %The first revision in a revlog (at the bottom of the image) has the %null ID in both of its parent slots. For a ``normal'' revision, its %first parent slot contains the ID of its parent revision, and its %second contains the null ID, indicating that the revision has only one %real parent. Any two revisions that have the same parent ID are %branches. A revision that represents a merge between branches has two %normal revision IDs in its parent slots. revlog$B$G$N:G=i$N%j%S%8%g%s!J?^$N0lHV2<!K$O(Bnull ID$B$rN>?F$r<($9%9%m%C%H$N(B $BN>J}$K;}$A!$$3$N%j%S%8%g%s$,<B:]$K$O$?$@0l$D$N?F$7$+;}$?$J$$$3$H$rI=$7$F(B $B$$$k!%F1$8?F$N(BID$B$r;}$DG$0U$N(B2$B$D$N%j%S%8%g%s$O%V%i%s%A$G$"$k!%(B $B%V%i%s%A4V$N%^!<%8$rI=$9%j%S%8%g%s$O!$(B2$B$D$N%N!<%^%k%j%S%8%g%s(BID$B$rN>?F$N(B $B%9%m%C%H$K;}$D!%(B \begin{figure}[ht] \centering \includegraphics{revlog} \caption{} \label{fig:concepts:revlog} \end{figure} %\section{The working directory} \section{$B%o!<%-%s%0%G%#%l%/%H%j(B} %In the working directory, Mercurial stores a snapshot of the files %from the repository as of a particular changeset. Mercurial$B$O%j%]%8%H%j$N$"$kFCDj$N%A%'%s%8%;%C%H$N%U%!%$%k%9%J%C%W%7%g%C%H(B $B$r%o!<%-%s%0%G%#%l%/%H%jFb$K;}$D!%(B %The working directory ``knows'' which changeset it contains. When you %update the working directory to contain a particular changeset, %Mercurial looks up the appropriate revision of the manifest to find %out which files it was tracking at the time that changeset was %committed, and which revision of each file was then current. It then %recreates a copy of each of those files, with the same contents it had %when the changeset was committed. $B%o!<%-%s%0%G%#%l%/%H%j$,$I$N%A%'%s%8%;%C%H$K99?7$5$l$F$$$k$,$"$k$N$+$O4{(B $BCN$G$"$k!%%o!<%-%s%0%G%#%l%/%H%j$,FCDj$N%A%'%s%8%;%C%H$K$J$k$h$&$K99?7$9(B $B$k:]!$(B Mercurial$B$OE,@Z$J%j%S%8%g%s$N%^%K%U%'%9%H$r8!:w$7!$$=$N%A%'%s%8%;%C(B $B%H$,%3%_%C%H$5$l$?;~E@$G$I$N%U%!%$%k$,DI@W$5$l$F$$$k$+$rD4$Y!$3F!9$N%U%!(B $B%$%k$N%j%S%8%g%s$rFCDj$9$k!%$=$7$F%A%'%s%8%;%C%H$,%3%_%C%H$5$l$?;~E@$NFb(B $BMF$r$b$D%U%!%$%k$N%3%T!<$r:n@.$9$k!%(B %The \emph{dirstate} contains Mercurial's knowledge of the working %directory. This details which changeset the working directory is %updated to, and all of the files that Mercurial is tracking in the %working directory. \emph{dirstate}$B$K$O%o!<%-%s%0%G%#%l%/%H%j$K$D$$$F(BMercurial$B$,GD0.$7$F$$$k(B $B>pJs$,3JG<$5$l$F$$$k!%$=$NFbMF$O%o!<%-%s%0%G%#%l%/%H%j$,%"%C%W%G!<%H$5$l(B $B$F$$$k%A%'%s%8%;%C%H$*$h$S%o!<%-%s%0%G%#%l%/%H%jFb$G(BMercurial$B$,DI@W$7$F$$(B $B$kA4$F$N%U%!%$%k$K$D$$$F$N>\:Y$G$"$k!%(B %Just as a revision of a revlog has room for two parents, so that it %can represent either a normal revision (with one parent) or a merge of %two earlier revisions, the dirstate has slots for two parents. When %you use the \hgcmd{update} command, the changeset that you update to %is stored in the ``first parent'' slot, and the null ID in the second. %When you \hgcmd{merge} with another changeset, the first parent %remains unchanged, and the second parent is filled in with the %changeset you're merging with. The \hgcmd{parents} command tells you %what the parents of the dirstate are. revlog$B$K$*$1$k%j%S%8%g%s$,(B2$B$D$N?F$N>pJs$r3JG<$9$kNN0h$r;}$A!$DL>o$N%j%S%8%g(B $B%s!J?F$O(B1$B$D!K$^$?$O(B2$B$D$N?F$N%^!<%8$rI=8=$G$-$k$N$HF1MM$K(Bdirstate$B$b(B2$B$D$N?F(B $B$N$?$a$N%9%m%C%H$r;}$C$F$$$k!%(B\hgcmd{update}$B%3%^%s%I$r<B9T$9$k$H!$%"%C%W(B $B%G!<%H@h$N%A%'%s%8%;%C%H$,(B1$B$DL\$N?F$N%9%m%C%H$K5-O?$5$l!$(Bnull ID$B$,(B2$B$DL\$N(B $B?F$N%9%m%C%H$K5-O?$5$l$k!%B>$N%A%'%s%8%;%C%H$H(B\hgcmd{merge}$B$r9T$&$H!$:G=i(B $B$N?F$O$=$N$^$^$K!$(B2$BHVL\$N?F$O%^!<%8$9$k%A%'%s%8%;%C%H$H$J(B $B$k!%(B\hgcmd{parents}$B%3%^%s%I$G(Bdirstate$B$NN>?F$rCN$k$3$H$,$G$-$k!%(B %\subsection{What happens when you commit} \subsection{$B%3%_%C%H;~$K2?$,5/$-$k$N$+(B} %The dirstate stores parent information for more than just book-keeping %purposes. Mercurial uses the parents of the dirstate as \emph{the % parents of a new changeset} when you perform a commit. dirstate$B$O4IM}L\E*0U30$N>pJs$bJ]B8$7$F$$$k!%(B Mercurial$B$O!$%3%_%C%H$N:]$K(B dirstate$B$NN>?F$r(B\emph{$B?7$?$J%A%'%s%8%;%C%H$NN>?F(B}$B$H$7$FMQ$$$k!%(B \begin{figure}[ht] \centering \includegraphics{wdir} % \caption{The working directory can have two parents} \caption{$B%o!<%-%s%0%G%#%l%/%H%j$O(B2$B$D$N?F$r;}$AF@$k(B} \label{fig:concepts:wdir} \end{figure} %Figure~\ref{fig:concepts:wdir} shows the normal state of the working %directory, where it has a single changeset as parent. That changeset %is the \emph{tip}, the newest changeset in the repository that has no %children. $B?^(B~\ref{fig:concepts:wdir}$B$K%o!<%-%s%0%G%#%l%/%H%j$NDL>o>uBV$r<($9!%(B $B%j%]%8%H%j$N:G?7$N%A%'%s%8%;%C%H$O(B\emph{tip}$B$G!$;R$r0l@Z;}$?$J$$!%(B \begin{figure}[ht] \centering \includegraphics{wdir-after-commit} % \caption{The working directory gains new parents after a commit} \caption{$B%3%_%C%H8e!$%o!<%-%s%0%G%#%l%/%H%j$O?7$?$JN>?F$r;}$D(B} \label{fig:concepts:wdir-after-commit} \end{figure} %It's useful to think of the working directory as ``the changeset I'm %about to commit''. Any files that you tell Mercurial that you've %added, removed, renamed, or copied will be reflected in that %changeset, as will modifications to any files that Mercurial is %already tracking; the new changeset will have the parents of the %working directory as its parents. $B%o!<%-%s%0%G%#%l%/%H%j$,(B``$B%3%_%C%H$7$h$&$H$7$F$$$k%A%'%s%8%;%C%H(B''$B$G$"$k(B $B$H8+$J$9$3$H$OLr$KN)$D!%DI2C!$:o=|!$%j%M!<%`$^$?$O%3%T!<$7$?%U%!%$%k$r(B Mercurial$B$KG'<1$5$;$k$H!$$9$G$K(BMercurial$B$,DI@W$7$F$$$kG$0U$N%U%!%$%k$X$N(B $BJQ99$HF1MM!$$9$Y$F%A%'%s%8%;%C%H$KH?1G$5$l$k!%?7$?$J%A%'%s%8%;%C%H$O%o!<(B $B%-%s%0%G%#%l%/%H%j$NN>?F$rN>?F$H$7$F;}$D!%(B %After a commit, Mercurial will update the parents of the working %directory, so that the first parent is the ID of the new changeset, %and the second is the null ID. This is shown in %figure~\ref{fig:concepts:wdir-after-commit}. Mercurial doesn't touch %any of the files in the working directory when you commit; it just %modifies the dirstate to note its new parents. $B%3%_%C%H8e!$(BMercurial$B$O%o!<%-%s%0%G%#%l%/%H%j$NN>?F$r99?7$7!$(B1$B$DL\$N?F$,(B $B?7$?$J%A%'%s%8%;%C%H$N(BID$B!$(B2$BHVL\$r(Bnull ID$B$K$9$k!%$3$l$r(B $B?^(B~\ref{fig:concepts:wdir-after-commit}$B$K<($9!%(BMercurial$B$O%3%_%C%H;~$K%o!<(B $B%-%s%0%G%#%l%/%H%jFb$N%U%!%$%k$K$O0l@Z?($l$:!$(Bdirstate$B$K?7$?$JN>?F$r5-O?(B $B$9$k!%(B %\subsection{Creating a new head} \subsection{$B?7$?$J%X%C%I$r:n$k(B} %It's perfectly normal to update the working directory to a changeset %other than the current tip. For example, you might want to know what %your project looked like last Tuesday, or you could be looking through %changesets to see which one introduced a bug. In cases like this, the %natural thing to do is update the working directory to the changeset %you're interested in, and then examine the files in the working %directory directly to see their contents as they were when you %committed that changeset. The effect of this is shown in %figure~\ref{fig:concepts:wdir-pre-branch}. $B%o!<%-%s%0%G%#%l%/%H%j$r8=:_$N(Btip$B0J30$N%A%'%s%8%;%C%H$K99?7$9$k$3$H$O$$$5(B $B$5$+$b$*$+$7$J$3$H$G$O$J$$!%Nc$($P!$$3$NA0$N2PMKF|$K%W%m%8%'%/%H$,$I$N$h(B $B$&$J>uBV$G$"$C$?$+CN$j$?$$$H;W$&$+$b$7$l$J$$$7!$%A%'%s%8%;%C%H$N$&$A$N$I(B $B$l$,%P%0$r:.F~$5$;$?$+FM$-;_$a$?$$$H9M$($k$3$H$,$"$k$+$b$7$l$J$$!%$3$N$h(B $B$&$J>l9g!$%o!<%-%s%0%G%#%l%/%H%j$r6=L#$N$"$k%A%'%s%8%;%C%H$K99?7$7!$%A%'(B $B%s%8%;%C%H$r%3%_%C%H$7$?;~$K$=$l$i$,$I$N$h$&$G$"$C$?$+$r8+$k$?$a$K%o!<%-(B $B%s%0%G%#%l%/%H%jFb$N%U%!%$%k$rD4$Y$k$N$,<+A3$G$"$k!%$3$N1F6A$O(B $B?^(B~\ref{fig:concepts:wdir-pre-branch}$B$K<($9!%(B \begin{figure}[ht] \centering \includegraphics{wdir-pre-branch} % \caption{The working directory, updated to an older changeset} \caption{$B8E$$%A%'%s%8%;%C%H$X$H99?7$5$l$?%o!<%-%s%0%G%#%l%/%H%j(B} \label{fig:concepts:wdir-pre-branch} \end{figure} %Having updated the working directory to an older changeset, what %happens if you make some changes, and then commit? Mercurial behaves %in the same way as I outlined above. The parents of the working %directory become the parents of the new changeset. This new changeset %has no children, so it becomes the new tip. And the repository now %contains two changesets that have no children; we call these %\emph{heads}. You can see the structure that this creates in %figure~\ref{fig:concepts:wdir-branch}. $B%o!<%-%s%0%G%#%l%/%H%j$r8E$$%A%'%s%8%;%C%H$K99?7$7!$JQ99$r9T$C$F%3%_%C%H(B $B$9$k$H2?$,5/$3$k$@$m$&$+!)(B Mercurial$B$OA0=R$N$h$&$K?6Iq$&!%%o!<%-%s%0%G%#(B $B%l%/%H%j$NN>?F$O?7$?$J%A%'%s%8%;%C%H$NN>?F$H$J$k!%?7$?$J%A%'%s%8%;%C%H$O(B $B;R$r;}$?$:!$=>$C$F?7$?$J(Btip$B$H$J$k!%%j%]%8%H%j$K$O(B\emph{heads}$B$H8F$P$l$k(B2 $B$D$N%A%'%s%8%;%C%H$,$G$-$k!%$3$N;~$N9=B$$r(B $B?^(B~\ref{fig:concepts:wdir-branch}$B$K<($9!%(B \begin{figure}[ht] \centering \includegraphics{wdir-branch} % \caption{After a commit made while synced to an older changeset} \caption{$B8E$$%A%'%s%8%;%C%H$KF14|Cf$K%3%_%C%H$,9T$o$l$?>l9g(B} \label{fig:concepts:wdir-branch} \end{figure} %\begin{note} % If you're new to Mercurial, you should keep in mind a common % ``error'', which is to use the \hgcmd{pull} command without any % options. By default, the \hgcmd{pull} command \emph{does not} % update the working directory, so you'll bring new changesets into % your repository, but the working directory will stay synced at the % same changeset as before the pull. If you make some changes and % commit afterwards, you'll thus create a new head, because your % working directory isn't synced to whatever the current tip is. % % I put the word ``error'' in quotes because all that you need to do % to rectify this situation is \hgcmd{merge}, then \hgcmd{commit}. In % other words, this almost never has negative consequences; it just % surprises people. I'll discuss other ways to avoid this behaviour, % and why Mercurial behaves in this initially surprising way, later % on. %\end{note} \begin{note} Mercurial$B$r;H$$;O$a$?$P$+$j$G$"$l$P!$$h$/$"$k(B``$B%(%i!<(B''$B$r3P$($F$*$/$H$h(B $B$$!%$=$l$O(B\hgcmd{pull}$B%3%^%s%I$r%*%W%7%g%s$J$7$G<B9T$9$k$3$H$G$"$k!%%G%U%)(B $B%k%H$G$O(B\hgcmd{pull}$B$O%o!<%-%s%0%G%#%l%/%H%j$N99?7$r(B\emph{$B9T$o$J$$(B}$B!%$=$N(B $B$?$a!$%j%]%8%H%j$K$O?7$7$$%A%'%s%8%;%C%H$,E~Ce$7$F$$$k$N$K%o!<%-%s%0%G%#(B $B%l%/%H%j$OA02s(Bpull$B$7$?%A%'%s%8%;%C%H$N$^$^$G$"$k!%$3$3$G$J$s$i$+$NJQ99$r(B $B9T$C$F%3%_%C%H$7$h$&$H$9$k$H!$%o!<%-%s%0%G%#%l%/%H%j$,8=:_$N(Btip$B$KF14|$7$F(B $B$$$J$$$?$a!$?7$?$J%X%C%I$r:n$k$3$H$K$J$C$F$7$^$&!%(B ``$B%(%i!<(B''$B$H$$$&8@MU$r0zMQId$G3g$C$?$N$O!$$3$N>uBV$O(B\hgcmd{merge}$B$H(B \hgcmd{commit}$B$@$1$G2r>C$G$-$k$+$i$@!%8@$$BX$($k$H!$$3$N>uBV$O$[$H$s$I$N(B $B>l9g32$r$J$9$b$N$G$O$J$J$/!$C1$K%f!<%6$r6C$+$9DxEY$N$b$N$G$"$k!%$3$N?6Iq(B $B$rHr$1$kJL$NJ}K!$d!$$J$<(BMercurial$B$,$3$N$h$&$K6C$+$;$k$h$&$JJ}K!$GF0:n$9$k(B $B$N$+$K$D$$$F$O8e$[$I5DO@$9$k!%(B \end{note} %\subsection{Merging heads} \subsection{$B%X%C%I4V$N%^!<%8(B} %When you run the \hgcmd{merge} command, Mercurial leaves the first %parent of the working directory unchanged, and sets the second parent %to the changeset you're merging with, as shown in %figure~\ref{fig:concepts:wdir-merge}. \hgcmd{merge}$B%3%^%s%I$r<B9T$7$?;~!$(BMercurial$B$O%o!<%-%s%0%G%#%l%/%H%j$N:G(B $B=i$N?F$rJQ99$;$:;D$7!$(B2$BHVL\$N?F$r?^(B~\ref{fig:concepts:wdir-merge}$B$N$h$&(B $B$K%^!<%8@h$N%A%'%s%8%;%C%H$H$9$k!%(B \begin{figure}[ht] \centering \includegraphics{wdir-merge} % \caption{Merging two heads} \caption{2$B$D$N%X%C%I$N%^!<%8(B} \label{fig:concepts:wdir-merge} \end{figure} %Mercurial also has to modify the working directory, to merge the files %managed in the two changesets. Simplified a little, the merging %process goes like this, for every file in the manifests of both %changesets. Mercurial$B$O(B2$B$D$N%A%'%s%8%;%C%HFb$G4IM}$5$l$F$$$k%U%!%$%k$r%^!<%8$9$k$?$a(B $B$K%o!<%-%s%0%G%#%l%/%H%j$rJQ99$9$kI,MW$,$"$k!%>/$7C1=c2=$9$k$H!$%^!<%8%W(B $B%m%;%9$OAPJ}$N%A%'%s%8%;%C%H$N%^%K%U%'%9%HFb$K$"$kA4$F$N%U%!%$%k$KBP$7$F(B $B<!$N$h$&$K9T$o$l$k!%(B \begin{itemize} %\item If neither changeset has modified a file, do nothing with that % file. \item $B$I$A$i$N%A%'%s%8%;%C%H$G$bJQ99$5$l$F$$$J$$%U%!%$%k$KBP$7$F$O2?$b(B $B9T$o$J$$!%(B %\item If one changeset has modified a file, and the other hasn't, % create the modified copy of the file in the working directory. \item $BJQ99$5$l$?%U%!%$%k$,JRJ}$N%A%'%s%8%;%C%H$K4^$^$l!$$b$&0lJ}$K$O4^(B $B$^$l$J$$>l9g!$%o!<%-%s%0%G%#%l%/%H%j$KJQ99$5$l$?%3%T!<$,:n@.$5$l(B $B$k!%(B %\item If one changeset has removed a file, and the other hasn't (or % has also deleted it), delete the file from the working directory. \item $B0lJ}$N%A%'%s%8%;%C%H$G:o=|$5$l$?%U%!%$%k$,$"$j!$$b$&0lJ}$,$=$N%U%!(B $B%$%k$r4^$^$J$$$+!$F1MM$K:o=|$5$l$F$$$k>l9g$O%o!<%-%s%0%G%#%l%/%H(B $B%j$+$i$=$N%U%!%$%k$r:o=|$9$k!%(B %\item If one changeset has removed a file, but the other has modified % the file, ask the user what to do: keep the modified file, or remove % it? \item $B0lJ}$N%A%'%s%8%;%C%H$G%U%!%$%k$,:o=|$5$l$F$*$j!$$b$&0lJ}$G$O$=$N(B $B%U%!%$%k$,JQ99$5$l$F$$$k>l9g$O!$JQ99$5$l$?%U%!%$%k$r0];}$9$k$+%U%!(B $B%$%k$r>C5n$9$k$+$+%f!<%6$K?R$M$k!%(B %\item If both changesets have modified a file, invoke an external % merge program to choose the new contents for the merged file. This % may require input from the user. \item $BN>J}$N%A%'%s%8%;%C%H$G%U%!%$%k$,JQ99$5$l$F$$$k>l9g!$%^!<%88e$N%U%!(B $B%$%k$NFbMF$rA*Br$9$k$?$a$K30It$N%^!<%8%W%m%0%i%`$r5/F0$9$k!%$3$l(B $B$r9T$&$?$a$K$O%f!<%6$NF~NO$,I,MW$G$"$k!%(B %\item If one changeset has modified a file, and the other has renamed % or copied the file, make sure that the changes follow the new name % of the file. \item $B0lJ}$N%A%'%s%8%;%C%H$G%U%!%$%k$,JQ99$5$l$F$*$j!$$b$&0lJ}$G$O%U%!(B $B%$%k$,%j%M!<%`$^$?$O%3%T!<$5$l$F$$$k>l9g!$JQ99$O?7$7$$L>A0$N%U%!(B $B%$%k$K<h$j9~$^$l$k!%(B \end{itemize} %There are more details---merging has plenty of corner cases---but %these are the most common choices that are involved in a merge. As %you can see, most cases are completely automatic, and indeed most %merges finish automatically, without requiring your input to resolve %any conflicts. $B>\$7$/=R$Y$l$P%^!<%8$K$O$$$m$$$m$JFC<lNc$,$"$k!%$7$+$7$3$3$G$O:G$bIaDL$N(B $BA*Br$K$D$$$F@bL@$9$k!%$3$l$^$G8+$F$-$?$h$&$K!$BgH>$N%1!<%9$O40A4$K<+F0$G(B $B$"$j!$<B:]$KBgH>$N%^!<%8$O>WFM$r2r7h$9$k$?$a$KF~NO$r5a$a$k$3$H$J$/<+F0E*(B $B$K40N;$9$k!%(B %When you're thinking about what happens when you commit after a merge, %once again the working directory is ``the changeset I'm about to %commit''. After the \hgcmd{merge} command completes, the working %directory has two parents; these will become the parents of the new %changeset. $B%^!<%88e$K%3%_%C%H$r9T$&$H$-2?$,5/$3$k$+$r9M$($k>l9g$O$d$O$j%o!<%-%s%0%G%#(B $B%l%/%H%j$r(B``$B$3$l$+$i%3%_%C%H$7$h$&$H$9$k%A%'%s%8%;%C%H(B''$B$H9M$($k$H$h$$!%(B \hgcmd{merge}$B%3%^%s%I$,40N;$7$?8e!$%o!<%-%s%0%G%#%l%/%H%j$O(B2$B$D$N?F$r;}(B $B$A!$$3$l$i$O?7$?$J%A%'%s%8%;%C%H$NN>?F$H$J$k!%(B %Mercurial lets you perform multiple merges, but you must commit the %results of each individual merge as you go. This is necessary because %Mercurial only tracks two parents for both revisions and the working %directory. While it would be technically possible to merge multiple %changesets at once, the prospect of user confusion and making a %terrible mess of a merge immediately becomes overwhelming. Mercurial$B$OJ#?t2s$N%^!<%8$rB%$9!%$3$3$G$=$l$>$l$N%^!<%8$N7k2L$r<+J,<+?H$G(B $B%3%_%C%H$7$J$1$l$P$J$i$J$$!%$3$l$O(BMercurial$B$,%j%S%8%g%s$H%o!<%-%s%0%G%#%l(B $B%/%H%j$NAPJ}$K$D$$$F(B2$B$D$N?F$N$_$rDI@W$9$k$3$H$K$h$k!%J#?t$N%A%'%s%8%;%C%H(B $B$r0lEY$K%^!<%8$9$k$3$H$O5;=QE*$K$O2DG=$@$,!$%^!<%8$K$h$k:.Mp$r0z$-5/$3(B $B$7!$<}=&$,$D$+$J$/$J$k8+9~$_$,Bg$-$$!%(B %\section{Other interesting design features} \section{$B@_7W$NB>$N6=L#?<$$E@(B} %In the sections above, I've tried to highlight some of the most %important aspects of Mercurial's design, to illustrate that it pays %careful attention to reliability and performance. However, the %attention to detail doesn't stop there. There are a number of other %aspects of Mercurial's construction that I personally find %interesting. I'll detail a few of them here, separate from the ``big %ticket'' items above, so that if you're interested, you can gain a %better idea of the amount of thinking that goes into a well-designed %system. $BA0@a$G(BMercurial$B$N@_7W$N:G$b=EMW$JLL$K$D$$$F<h$j>e$2!$?.Mj@-$H@-G=$K:Y?4$N(B $BCm0U$rJ'$C$F$$$k$3$H$r6/D4$7$?!%$7$+$7:YIt$X$NCm0U$O$=$l$@$1$KN1$^$i$J$$!%(B Mercurial$B$N9=B$$K$O!$8D?ME*$K6=L#?<$/46$8$?E@$,B?!9$"$k!%9*L/$K@_7W$5$l$?(B $B%7%9%F%`$NGX8e$K$"$k%"%$%G%#%"$K$D$$$FFI<T$,6=L#$r;}$D$J$i$P!$$h$j?<$$M}(B $B2r$,=PMh$k$h$&!$A0=R$7$?Bg$-$J3g$j$H$OJL$K$=$N(B2,3$B$K$D$$$F<h$j>e$2$F$_$h$&(B $B$H;W$&!%(B %\subsection{Clever compression} \subsection{$B8-$$05=L(B} %When appropriate, Mercurial will store both snapshots and deltas in %compressed form. It does this by always \emph{trying to} compress a %snapshot or delta, but only storing the compressed version if it's %smaller than the uncompressed version. $BE,@Z$J>l9g!$(BMercurial$B$O%9%J%C%W%7%g%C%H$H:9J,$r05=L$5$l$?7A<0$GJ]B8$9$k!%(B Mercurial$B$O>o$K%9%J%C%W%7%g%C%H$d:9J,$N05=L$r(B\emph{$B;n$_$k(B}$B$,!$$=$l$rJ]B8(B $B$9$k$N$O05=L$5$l$?%P!<%8%g%s$,85$N%P!<%8%g%s$h$j$b>.$5$$;~$N$_$G$"$k!%(B %This means that Mercurial does ``the right thing'' when storing a file %whose native form is compressed, such as a \texttt{zip} archive or a %JPEG image. When these types of files are compressed a second time, %the resulting file is usually bigger than the once-compressed form, %and so Mercurial will store the plain \texttt{zip} or JPEG. $B$D$^$j!$(BMercurial$B$O(B\texttt{zip}$B%"!<%+%$%V$d(BJPEG$B2hA|$J$I$N$h$&$K85!905=L$5(B $B$l$F$$$k%U%!%$%k$NJ]B8$r(B``$B@5$7$$$d$jJ}(B''$B$G9T$&!%$3$l$i$N%U%!%$%k$G$O!$:9(B $BJ,<h$C$F05=L$r9T$C$F$b7k2L$H$7$FF@$i$l$k%U%!%$%k$ODL>o!$85$N%U%!%$%k$h$j(B $B$bBg$-$/$J$k!%$=$3$G(BMercurial$B$O(B\texttt{zip}$B$d(BJPEG$B$r$=$N$^$^J]B8$9$k!%(B %Deltas between revisions of a compressed file are usually larger than %snapshots of the file, and Mercurial again does ``the right thing'' in %these cases. It finds that such a delta exceeds the threshold at %which it should store a complete snapshot of the file, so it stores %the snapshot, again saving space compared to a naive delta-only %approach. $BDL>o!$05=L$5$l$?%U%!%$%k$N%j%S%8%g%s4V$N:9J,$O%U%!%$%k$N%9%J%C%W%7%g%C%H(B $B$h$jBg$-$$!%$3$3$G$b(BMercurial$B$O(B``$B@5$7$$$d$jJ}(B''$B$rMQ$$$F$$$k!%$3$N$h$&$J(B $B>u67$G!$:9J,$N%5%$%:$,%U%!%$%k$N40A4$J%9%J%C%W%7%g%C%H$H$7$FJ]B8$7$?J}$,(B $BM-Mx$H$J$kogCM$r1[$($k$H!$:9J,$G$O$J$/%9%J%C%W%7%g%C%H$rJ]B8$9$k!%$3$N$h(B $B$&$K$7$FC1=c$K:9J,$N$_$r5-O?$9$k%"%W%m!<%A$h$j$b5-21NN0h$r@aLs$7$F$$$k!%(B %\subsubsection{Network recompression} \subsubsection{$B%M%C%H%o!<%/:F05=L(B} %When storing revisions on disk, Mercurial uses the ``deflate'' %compression algorithm (the same one used by the popular \texttt{zip} %archive format), which balances good speed with a respectable %compression ratio. However, when transmitting revision data over a %network connection, Mercurial uncompresses the compressed revision %data. $B%G%#%9%/$K%j%S%8%g%s$rJ]B8$9$k:]!$(BMercurial$B$O(B``deflate''$B05=L%"%k%4%j%:%`(B $B$rMQ$$$k!%!J$3$l$O?M5$$N9b$$(B\texttt{zip}$B%"!<%+%$%V%U%)!<%^%C%H$HF1$8%"%k(B $B%4%j%:%`$G$"$k!%!K$3$N%"%k%4%j%:%`$O9b$$05=LN($H9bB.@-$r%P%i%s%9$5$;$F$$(B $B$k!%$7$+$7%j%S%8%g%s%G!<%?$r%M%C%H%o!<%/$GEAAw$9$k:]$K$O(BMercurial$B$O05=L$5(B $B$l$F$$$k%j%S%8%g%s%G!<%?$r?-D9$9$k!%(B %If the connection is over HTTP, Mercurial recompresses the entire %stream of data using a compression algorithm that gives a better %compression ratio (the Burrows-Wheeler algorithm from the widely used %\texttt{bzip2} compression package). This combination of algorithm %and compression of the entire stream (instead of a revision at a time) %substantially reduces the number of bytes to be transferred, yielding %better network performance over almost all kinds of network. HTTP$B$K$h$k@\B3$N>l9g!$(BMercurial$B$O%G!<%?%9%H%j!<%`A4BN$r$h$j05=LN($N9b$$%"(B $B%k%4%j%:%`!J9-$/MQ$$$i$l$F$$$k05=L%Q%C%1!<%8$G$"$k(B\texttt{bzip2}$B$G;H$o$l(B $B$F$$$k(BBurrows-Wheeler$B%"%k%4%j%:%`!K$G:F05=L$9$k!%$3$N%"%k%4%j%:%`$H!$!J%j(B $B%S%8%g%sKh$G$J$/!K%9%H%j!<%`A4BN$r05=L$9$k$3$H$K$h$j!$Aw?.$5$l$k%P%$%H?t(B $B$OBg$-$/Dc8:$5$l!$$"$i$f$k%M%C%H%o!<%/$G$h$$@-G=$r$($k$3$H$,$G$-$k!%(B %(If the connection is over \command{ssh}, Mercurial \emph{doesn't} %recompress the stream, because \command{ssh} can already do this %itself.) $B!J(B\command{ssh}$B$K$h$k@\B3$N>l9g!$(BMercurial$B$O%9%H%j!<%`$N:F05=L$O9T$o$J(B $B$$!%(B\command{ssh}$B%3%^%s%I<+BN$,05=L$r9T$&$?$a$G$"$k!%!K(B %\subsection{Read/write ordering and atomicity} \subsection{$BFI$_=q$-$N=g=x$H%"%H%_%C%/@-(B} %Appending to files isn't the whole story when it comes to guaranteeing %that a reader won't see a partial write. If you recall %figure~\ref{fig:concepts:metadata}, revisions in the changelog point to %revisions in the manifest, and revisions in the manifest point to %revisions in filelogs. This hierarchy is deliberate. $B%U%!%$%k$X$NDI5-$OFI$_<j$,ItJ,%U%!%$%k$rFI$^$J$$$3$H$NJ]>Z$H$7$F$O==J,$G(B $B$O$J$$!%(B $B?^(B~\ref{fig:concepts:metadata}$B$r;W$$5/$3$9$H!$%A%'%s%8%m%0Fb$N%j(B $B%S%8%g%s$O%^%K%U%'%9%HFb$N%j%S%8%g%s$r;X$7<($7$F$*$j!$%^%K%U%'%9%HFb$N%j(B $B%S%8%g%s$O%U%!%$%k%m%0Fb$N%j%S%8%g%s$r;X$7<($7$F$$$?!%$3$N3,AX9=B$$O=EMW(B $B$J0UL#$r;}$C$F$$$k!%(B %A writer starts a transaction by writing filelog and manifest data, %and doesn't write any changelog data until those are finished. A %reader starts by reading changelog data, then manifest data, followed %by filelog data. $B=q$-<j$O%U%!%$%k%m%0$H%^%K%U%'%9%H$r=q$-9~$`$3$H$G%H%i%s%6%/%7%g%s$r(B $B3+;O$9$k$,!$$3$l$i$,40N;$9$k$^$G%A%'%s%8%m%0%G!<%?$N=q$-9~$_$O9T$o$J$$!%(B $B0lJ}!$FI$_<j$O%A%'%s%8%m%0%G!<%?!$%^%K%U%'%9%H%G!<%?!$%U%!%$%k%m%0%G!<%?(B $B$N=g$KFI$_=P$7$r9T$&!%(B %Since the writer has always finished writing filelog and manifest data %before it writes to the changelog, a reader will never read a pointer %to a partially written manifest revision from the changelog, and it will %never read a pointer to a partially written filelog revision from the %manifest. $B=q$-<j$O>o$K%U%!%$%k%m%0$H%^%K%U%'%9%H%G!<%?$r%A%'%s%8%m%0$NA0$K=q$-9~$_(B $B=*N;$7$F$$$k$?$a!$FI$_<j$OItJ,E*$K=q$+$l$?%^%K%U%'%9%H%j%S%8%g%s$X$N%]%$(B $B%s%?$r$r%A%'%s%8%m%0$+$iFI$_=P$9$3$H$O$J$$!%$^$?ItJ,E*$K=q$+$l$?%U%!%$%k(B $B%m%0%j%S%8%g%s$X$N%]%$%s%?$r%^%K%U%'%9%H$+$iFI$_=P$9$3$H$b$J$$!%(B %\subsection{Concurrent access} \subsection{$BF1;~%"%/%;%9(B} %The read/write ordering and atomicity guarantees mean that Mercurial %never needs to \emph{lock} a repository when it's reading data, even %if the repository is being written to while the read is occurring. %This has a big effect on scalability; you can have an arbitrary number %of Mercurial processes safely reading data from a repository safely %all at once, no matter whether it's being written to or not. $BFI$_=q$-$N=g=x$H%"%H%_%C%/@-$NJ]>Z$K$h$j!$(BMercurial$B$G$O%G!<%?$NFI$_=P$7;~(B $B$K%j%]%8%H%j$N(B\emph{$B%m%C%/(B}$B$,ITMW$K$J$C$F$$$k!%FI$_=P$7Cf$K=q$-9~$_$,H/@8(B $B$7$?$H$7$F$bF1MM$G$"$k!%$3$N$3$H$O%9%1!<%i%S%j%F%#$KBg$-$J8z2L$r$b$?$i(B $B$9!%B??t$N(BMercurial$B%W%m%;%9$,$"$C$F$b!$%j%]%8%H%j$X$N=q$-9~$_$NM-L5$K4X$o(B $B$i$:!$%j%]%8%H%j$+$i0lEY$K0BA4$K%G!<%?$rFI$_=P$9$3$H$,$G$-$k!%(B %The lockless nature of reading means that if you're sharing a %repository on a multi-user system, you don't need to grant other local %users permission to \emph{write} to your repositoryin order for them %to be able to clone it or pull changes from it; they only need %\emph{read} permission. (This is \emph{not} a common feature among %revision control systems, so don't take it for granted! Most require %readers to be able to lock a repository to access it safely, and this %requires write permission on at least one directory, which of course %makes for all kinds of nasty and annoying security and administrative %problems.) Mercurial$B$G$O!$%m%C%/L5$7$GFI$_=P$7$r9T$&$?$a!$%^%k%A%f!<%6%7%9%F%`>e$G%j(B $B%]%8%H%j$r6&M-$7$F$$$k>l9g$G$b(Bclone$B$d(Bpull$B$r9T$*$&$H$9$kB>$N%m!<%+%k%f!<%6(B $B$K%j%]%8%H%j$X$N(B\emph{$B=q$-9~$_(B}$B5v2D$rM?$($kI,MW$O$J$$!%H`$i$K$O(B\emph{$BFI$_(B $B=P$7(B}$B5v2D$,$"$l$P$h$$!%!JB>$N%j%S%8%g%s%3%s%H%m!<%k%7%9%F%`$G$O$3$&$O$$$+(B $B$:!$BgH>$N%7%9%F%`$G$OFI$_<j$,0BA4$K%j%]%8%H%j$K%"%/%;%9$9$k$?$a$K%m%C%/(B $B$r<hF@$9$k$3$H$rI,MW$H$9$k!%$3$l$O$9$J$o$AFI$_<j$,>/$J$/$H$b(B1$B$D$N%G%#%l%/(B $B%H%j$KBP$7$F=q$-9~$_5v2D$r;}$C$F$$$J$1$l$P$J$i$J$$$3$H$r0UL#$9$k!%$3$N$?(B $B$a$K%;%-%e%j%F%#$d4IM}>e$NLq2p$JLdBj$,H/@8$7F@$k!%!K(B %Mercurial uses locks to ensure that only one process can write to a %repository at a time (the locking mechanism is safe even over %filesystems that are notoriously hostile to locking, such as NFS). If %a repository is locked, a writer will wait for a while to retry if the %repository becomes unlocked, but if the repository remains locked for %too long, the process attempting to write will time out after a while. %This means that your daily automated scripts won't get stuck forever %and pile up if a system crashes unnoticed, for example. (Yes, the %timeout is configurable, from zero to infinity.) Mercurial$B$O0lEY$K(B1$B%W%m%;%9$@$1$,%j%]%8%H%j$K=q$-9~$`$3$H$rJ]>Z$9$k$?$a$K(B $B%m%C%/$r;H$C$F$$$k!%!J(BMercurial$B$NMQ$$$k%m%C%/%a%+%K%:%`$O(BNFS$B$N$h$&$K%m%C(B $B%/$HAj@-$N0-$$$3$H$GM-L>$J%U%!%$%k%7%9%F%`>e$G$b0BA4$G$"$k!%!K%j%]%8%H%j(B $B$,%m%C%/$5$l$k$H!$=q$-9~$_%W%m%;%9$O%j%]%8%H%j$,%"%s%m%C%/$5$l$k$^$G$7$P(B $B$i$/BT$D!%$7$+$7%j%]%8%H%j$,D9;~4V$K$o$?$C$F%m%C%/$5$lB3$1$k>l9g$O!$=q$-(B $B9~$_$7$h$&$H$9$k%W%m%;%9$O%?%$%`%"%&%H$9$k!%$3$l$O!$Nc$($P!$F|>oMQ$$$k<+(B $BF0%9%/%j%W%H$O1J1s$K%9%?%C%/$9$k$o$1$G$O$J$$$3$H$r0UL#$9$k!%!J$b$A$m$s%?(B $B%$%`%"%&%H$^$G$N;~4V$O%<%m$+$iL58B$N4V$G@_Dj$+$N$&$G$"$k!K(B %\subsubsection{Safe dirstate access} \subsubsection{$B0BA4$J(Bdirstate$B%"%/%;%9(B} %As with revision data, Mercurial doesn't take a lock to read the %dirstate file; it does acquire a lock to write it. To avoid the %possibility of reading a partially written copy of the dirstate file, %Mercurial writes to a file with a unique name in the same directory as %the dirstate file, then renames the temporary file atomically to %\filename{dirstate}. The file named \filename{dirstate} is thus %guaranteed to be complete, not partially written. $B%j%S%8%g%s%G!<%?$N;~$HF1MM$K!$(BMercurial$B$O(Bdirstate$B%U%!%$%k$rFI$_=P$9:]$K$O(B $B%m%C%/$r9T$o$J$$!%%m%C%/$r9T$&$N$O=q$-9~$_$N;~$N$_$G$"$k!%0lIt$N$_$,=q$-(B $B9~$^$l$?(Bdirstate$B%U%!%$%k$rFI$_9~$^$J$$$h$&$K$9$k$?$a!$(B Mercurial$B$OF1$8%G%#(B $B%l%/%H%jFb$K%f%K!<%/$JL>A0$G(Bdirstate$B%U%!%$%k$r=q$-!$$3$N0l;~%U%!%$%k$r%"(B $B%H%_%C%/$K(B\filename{dirstate}$B$K%j%M!<%`$9$k!%$3$l$K$h(B $B$j!$(B\filename{dirstate}$B%U%!%$%k$O>o$K40A4$G$"$k$3$H$,J]>Z$5$l$k!%(B %\subsection{Avoiding seeks} \subsection{$B%7!<%/$N2sHr(B} %Critical to Mercurial's performance is the avoidance of seeks of the %disk head, since any seek is far more expensive than even a %comparatively large read operation. Mercurial$B$N@-G=$K$O!$%G%#%9%/%X%C%I$N%7!<%/$rHr$1$k$3$H$,IT2D7g$G$"$k!%(B $B%7!<%/$OBg5,LO$JFI$_=P$7A`:n$HHf3S$7$F$bHs>o$K9b$/$D$/!%(B %This is why, for example, the dirstate is stored in a single file. If %there were a dirstate file per directory that Mercurial tracked, the %disk would seek once per directory. Instead, Mercurial reads the %entire single dirstate file in one step. $B$=$NM}M3$O!$Nc$($P!$(Bdirstate$B$O(B1$B$D$N%U%!%$%k$KJ]B8$5$l$F$$$k$?$a$G!$(B Mercurial$B$,DI@W$7$F$$$k(Bdirstate$B%U%!%$%k$,%G%#%l%/%H%jKh$K$"$k(B $B$H!$(BMercurial$B$O%G%#%l%/%H%jKh$K%7!<%/$r9T$&$3$H$K$J$k!%<B:]$K$O(BMercurial $B$OA4BN$G0l$D$N(Bdirstate$B%U%!%$%k$r%o%s%9%F%C%W$GFI$`!%(B %Mercurial also uses a ``copy on write'' scheme when cloning a %repository on local storage. Instead of copying every revlog file %from the old repository into the new repository, it makes a ``hard %link'', which is a shorthand way to say ``these two names point to the %same file''. When Mercurial is about to write to one of a revlog's %files, it checks to see if the number of names pointing at the file is %greater than one. If it is, more than one repository is using the %file, so Mercurial makes a new copy of the file that is private to %this repository. Mercurial$B$O%j%]%8%H%j$r%m!<%+%k%9%H%l!<%8$K%/%m!<%s$9$k:]$K(B``$B%3%T!<%*%s%i(B $B%$%H(B''$B<jK!$r;H$C$F$$$k!%85$N%j%]%8%H%j$+$i?7$7$$%j%]%8%H%j$XA4$F$N(Brevlog $B%U%!%$%k$r%3%T!<$9$k$N$G$O$J$/!$%O!<%I%j%s%/$r:n@.$9$k!%%O!<%I%j%s%/$OF1(B $B0l$N%U%!%$%k$r;X$7<($9JLL>$r:n$k4JC1$JJ}K!$G$"$k!%(B Mercurial$B$O(Brevlog$B%U%!(B $B%$%k$K=q$-9~$_$r9T$&:]$K%U%!%$%k$r<($9L>A0$,(B2$B$D0J>e$"$k2TF/$+$r%A%'%C%/$9(B $B$k!%(B 2$B$D0J>e$NL>A0$,$"$k>l9g!$(B2$B$D0J>e$N%j%]%8%H%j$,%U%!%$%k$r;HMQ$7$F$*(B $B$j!$(BMercurial$B$O%U%!%$%k$N%j%]%8%H%j$K8GM-$J?7$7$$%3%T!<$r:n@.$9$k!%(B %A few revision control developers have pointed out that this idea of %making a complete private copy of a file is not very efficient in its %use of storage. While this is true, storage is cheap, and this method %gives the highest performance while deferring most book-keeping to the %operating system. An alternative scheme would most likely reduce %performance and increase the complexity of the software, each of which %is much more important to the ``feel'' of day-to-day use. $B%j%S%8%g%s%3%s%H%m!<%k%7%9%F%`$N3+H/<T$N4v?M$+$O!$%U%!%$%k$N40A4$J%W%i%$(B $B%Y!<%H%3%T!<$r:n$k$H$$$&%"%$%G%#%"$O!$%9%H%l!<%8$NMxMQNL$N4QE@$+$i$"$^$j(B $B8zN(E*$G$J$$$H;XE&$7$F$$$k!%$3$l$O;v<B$G$"$k$,!$%9%H%l!<%8$O0B2A$G$"$j!$(B $B$3$NJ}K!$O(BOS$B>e$G:9J,$r<h$k>l9g:G9b$N@-G=$r$b$?$i$9!%$=$NB>$N<jK!$O@-G=$r(B $BB;$J$$!$%=%U%H%&%'%"$,J#;($K$J$k2DG=@-$,9b$$!%$3$l$i$OF|!9$N;HMQ46$h$j$b(B $B$:$C$H=EMW$G$"$k!%(B %\subsection{Other contents of the dirstate} \subsection{dirstate$B$NB>$NFbMF(B} %Because Mercurial doesn't force you to tell it when you're modifying a %file, it uses the dirstate to store some extra information so it can %determine efficiently whether you have modified a file. For each file %in the working directory, it stores the time that it last modified the %file itself, and the size of the file at that time. Mercurial$B$O!$%U%!%$%k$rJQ99$7$?>l9g$G$b!$JQ99$N?=9p$r6/@)$7$J$$$?$a!$(B dirstate$B$KDI2C$N>pJs$rJ]B8$9$k$3$H$G%U%!%$%k$rJQ99$7$?$+$I$&$+8z2LE*$KH=(B $BJL$9$k!%%o!<%-%s%0%G%#%l%/%H%j$N$9$Y$F$N%U%!%$%k$K$D$$$F!$:G8e$K%U%!%$%k(B $B$,JQ99$5$l$?;~9o$H!$$=$N:]$N%U%!%$%k%5%$%:$r5-O?$7$F$$$k!%(B %When you explicitly \hgcmd{add}, \hgcmd{remove}, \hgcmd{rename} or %\hgcmd{copy} files, Mercurial updates the dirstate so that it knows %what to do with those files when you commit. $BL@<(E*$K%U%!%$%k$r(B\hgcmd{add}, \hgcmd{remove}, \hgcmd{rename} $B$^$?$O(B \hgcmd{copy}$B$7$?>l9g!$(BMercurial$B$O(Bdirstate$B$r99?7$7!$%3%_%C%H$N:]$K$=$l$i(B $B$N%U%!%$%k$r$I$&<h$j07$&$+$rH=CG$9$k!%(B %When Mercurial is checking the states of files in the working %directory, it first checks a file's modification time. If that has %not changed, the file must not have been modified. If the file's size %has changed, the file must have been modified. If the modification %time has changed, but the size has not, only then does Mercurial need %to read the actual contents of the file to see if they've changed. %Storing these few extra pieces of information dramatically reduces the %amount of data that Mercurial needs to read, which yields large %performance improvements compared to other revision control systems. Mercurial$B$,%o!<%-%s%0%G%#%l%/%H%j$N%U%!%$%k$N>uBV$r%A%'%C%/$9$k:]$O!$$^$:(B $B%U%!%$%k$N99?7F|;~$rD4$Y$k!%$3$l$,JQ99$5$l$F$$$J$$>l9g$O%U%!%$%k$OJQ99$,(B $B$J$$$H$$$&$3$H$,$o$+$k!%%U%!%$%k%5%$%:$,JQ$o$C$F$$$k>l9g$O!$%U%!%$%k$,JQ(B $B99$5$l$?$3$H$,$o$+$k!%99?7F|;~$,JQ$o$C$F$$$k$,!$%5%$%:$,F1$8>l9g$O(B Mercurial$B$O%U%!%$%k$NFbMF$rD>@\8+$F!$JQ99$5$l$F$$$k$+$I$&$+$rH=CG$9$kI,MW(B $B$,$"$k!%$3$l$i$N$4$/6O$+$N>pJs$rJ]B8$9$k$3$H$K$h$C$F!$(BMercurial$B$O%G!<%?$N(B $BFI$_<h$jNL$r7`E*$K:o8:$7!$B>$N%j%S%8%g%s%3%s%H%m!<%k%7%9%F%`$HHf3S$7$FBg(B $B$-$J@-G=8~>e$rC#@.$7$F$$$k!%(B %%% Local Variables: %%% mode: yatex %%% TeX-master: "00book" %%% End: