view ja/concepts.tex @ 783:b15bea650f30

started tour-basic.tex

%\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: