Mercurial > hgbook
changeset 782:43556decb81f
finished concepts.tex
| author | Yoshiki Yazawa <yaz@honeyplanet.jp> |
|---|---|
| date | Wed, 03 Jun 2009 15:41:08 +0900 |
| parents | 93d19b27859c |
| children | b15bea650f30 |
| files | ja/concepts.tex ja/todo.txt |
| diffstat | 2 files changed, 345 insertions(+), 76 deletions(-) [+] |
line wrap: on
line diff
--- a/ja/concepts.tex Tue May 12 17:49:11 2009 +0900 +++ b/ja/concepts.tex Wed Jun 03 15:41:08 2009 +0900 @@ -162,7 +162,7 @@ %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!$%U%!%$%k%m%0$NEZBf$K;H$o$l$F$$$k$O6&DL$N(B +$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} @@ -281,16 +281,6 @@ $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} @@ -302,6 +292,12 @@ %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 @@ -311,6 +307,13 @@ %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} @@ -319,17 +322,31 @@ %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 @@ -338,6 +355,13 @@ %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} @@ -347,11 +371,21 @@ %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 @@ -360,6 +394,12 @@ %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} @@ -373,6 +413,9 @@ %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 @@ -381,11 +424,23 @@ %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 @@ -396,6 +451,14 @@ %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} @@ -403,6 +466,9 @@ %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} @@ -416,6 +482,9 @@ %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} @@ -431,6 +500,12 @@ %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 @@ -438,6 +513,12 @@ %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} @@ -447,10 +528,19 @@ %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 werea when you +%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} @@ -468,6 +558,13 @@ %\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} @@ -494,6 +591,22 @@ % 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} @@ -502,6 +615,10 @@ %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} @@ -510,79 +627,141 @@ \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 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 If one changeset has modified a file, and the other hasn't, - create the modified copy of the file in the working directory. -\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 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 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 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 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. + +%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. -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 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. +%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. +%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. -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. +%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} @@ -594,6 +773,12 @@ %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 @@ -602,10 +787,19 @@ %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} @@ -615,17 +809,33 @@ %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} @@ -636,9 +846,15 @@ %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 repository in order for them +%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 @@ -647,6 +863,15 @@ %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 @@ -657,6 +882,15 @@ %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} @@ -668,6 +902,13 @@ %\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} @@ -690,7 +931,6 @@ %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 @@ -700,8 +940,12 @@ %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!%(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 @@ -711,6 +955,13 @@ %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} @@ -720,10 +971,19 @@ %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 @@ -734,6 +994,15 @@ %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"