Mercurial > hgbook

--- a/ja/daily.tex	Fri Jan 09 17:01:40 2009 +0900
+++ b/ja/daily.tex	Fri Jan 09 18:07:12 2009 +0900
@@ -5,30 +5,51 @@
 %\section{Telling Mercurial which files to track}
 \section{$BDI@W$9$Y$-%U%!%$%k$N(BMercurial$B$X$NEPO?(B}

-Mercurial does not work with files in your repository unless you tell
-it to manage them.  The \hgcmd{status} command will tell you which
-files Mercurial doesn't know about; it uses a ``\texttt{?}'' to
-display such files.
+%Mercurial does not work with files in your repository unless you tell
+%it to manage them.  The \hgcmd{status} command will tell you which
+%files Mercurial doesn't know about; it uses a ``\texttt{?}'' to
+%display such files.
+
+Mercurial$B$O!$%f!<%6$K$h$k%U%!%$%k4IM}$N;X<($,$J$$8B$j!$%j%]%8%H%jFb$N%U%!(B
+$B%$%k$G$"$C$F$b4IM}$r9T$o$J$$!%(BMercurial$B$,4IM}$7$J$$%U%!%$%k$O(B
+\hgcmd{status}$B%3%^%s%I$r<B9T$9$k$H(B``\texttt{?}''$B$HI=<($5$l$k!%(B

-To tell Mercurial to track a file, use the \hgcmd{add} command.  Once
-you have added a file, the entry in the output of \hgcmd{status} for
-that file changes from ``\texttt{?}'' to ``\texttt{A}''.
+%To tell Mercurial to track a file, use the \hgcmd{add} command.  Once
+%you have added a file, the entry in the output of \hgcmd{status} for
+%that file changes from ``\texttt{?}'' to ``\texttt{A}''.
+%\interaction{daily.files.add}
+
+Mercurial$B$K%U%!%$%k$NDI@W$r$5$;$k$K$O!$(B\hgcmd{add}$B%3%^%s%I$rMQ$$$k!%0lEY(B
+$B%U%!%$%k$rDI2C$9$k$H!$(B\hgcmd{status}$B%3%^%s%I$N=PNO$O(B``\texttt{?}''$B$+$i(B
+``\texttt{A}''$B$KJQ$o$k!%(B
 \interaction{daily.files.add}

-After you run a \hgcmd{commit}, the files that you added before the
-commit will no longer be listed in the output of \hgcmd{status}.  The
-reason for this is that \hgcmd{status} only tells you about
-``interesting'' files---those that you have modified or told Mercurial
-to do something with---by default.  If you have a repository that
-contains thousands of files, you will rarely want to know about files
-that Mercurial is tracking, but that have not changed.  (You can still
-get this information; we'll return to this later.)
+%After you run a \hgcmd{commit}, the files that you added before the
+%commit will no longer be listed in the output of \hgcmd{status}.  The
+%reason for this is that \hgcmd{status} only tells you about
+%``interesting'' files---those that you have modified or told Mercurial
+%to do something with---by default.  If you have a repository that
+%contains thousands of files, you will rarely want to know about files
+%that Mercurial is tracking, but that have not changed.  (You can still
+%get this information; we'll return to this later.)

-Once you add a file, Mercurial doesn't do anything with it
-immediately.  Instead, it will take a snapshot of the file's state the
-next time you perform a commit.  It will then continue to track the
-changes you make to the file every time you commit, until you remove
-the file.
+\hgcmd{commit}$B%3%^%s%I$r<B9T$9$k$H!$(Bcommit$B$NA0$KDI2C$7$?%U%!%$%k$O(B
+\hgcmd{status}$B$N=PNO$K8=$l$J$/$J$k!%$3$l$O!$(B\hgcmd{status}$B$,%G%U%)%k%H$G(B
+$B$OJQ99$r2C$($?$j!$(BMercurial$B$K2?$+$r$5$;$?$H$$$C$?(B``$BCmL\$9$Y$-(B''$B%U%!%$%k$N(B
+$B$_$rI=<($9$k$?$a$G$"$k!%?t@i$N%U%!%$%k$+$i$J$k%j%]%8%H%j$N>l9g!$(BMercurial$B$,(B
+$BDI@W$7$F$$$k$b$N$N!$JQ99$N2C$($i$l$F$$$J$$%U%!%$%k$K$D$$$F2?$+$rCN$j$?$$(B
+$B$H$$$&$3$H$O5)$G$"$k!%!J$b$A$m$sCN$j$?$$>l9g$O>pJs$rF@$k$3$H$b$G$-$k!%$3(B
+$B$l$K$D$$$F$O8e=R$9$k!%!K(B
+
+%Once you add a file, Mercurial doesn't do anything with it
+%immediately.  Instead, it will take a snapshot of the file's state the
+%next time you perform a commit.  It will then continue to track the
+%changes you make to the file every time you commit, until you remove
+%the file.
+
+$BDI2C$7$?%U%!%$%k$KBP$7$F(BMercurial$B$,D>$A$K9T$&$3$H$O2?$b$J$$$,!$$=$NBe$o$j(B
+$B$K<!2s$N%3%_%C%H;~$K%U%!%$%k>uBV$N%9%J%C%W%7%g%C%H$r<h$k!%$=$7$F%U%!%$%k(B
+$B$r:o=|$9$k$^$G%3%_%C%HKh$K%U%!%$%k$NJQ2=$rDI@W$9$k!%(B

 %\subsection{Explicit versus implicit file naming}
 \subsection{$BL@<(E*$J%U%!%$%kL?L>BP0EL[$N%U%!%$%kL?L>(B}
@@ -321,60 +342,99 @@
 %\subsection{Renaming files and merging changes}
 \subsection{$B%U%!%$%k$N%j%M!<%`$HJQ99$N%^!<%8(B}

-Since Mercurial's rename is implemented as copy-and-remove, the same
-propagation of changes happens when you merge after a rename as after
-a copy.
+%Since Mercurial's rename is implemented as copy-and-remove, the same
+%propagation of changes happens when you merge after a rename as after
+%a copy.
+
+Mercurial$B$N%j%M!<%`$O%3%T!<$H:o=|$H$7$F<BAu$5$l$F$*$j!$%j%M!<%`8e$K%^!<(B
+$B%8$r9T$&$N$H!$%3%T!<8e$K%^!<%8$r9T$&$N$G$OF1$8JQ99$NGH5Z$,5/$-$k!%(B
+
+%If I modify a file, and you rename it to a new name, and then we merge
+%our respective changes, my modifications to the file under its
+%original name will be propagated into the file under its new name.
+%(This is something you might expect to ``simply work,'' but not all
+%revision control systems actually do this.)

-If I modify a file, and you rename it to a new name, and then we merge
-our respective changes, my modifications to the file under its
-original name will be propagated into the file under its new name.
-(This is something you might expect to ``simply work,'' but not all
-revision control systems actually do this.)
+$B;d$,%U%!%$%k$rJQ99$7!$$"$J$?$,$=$N%U%!%$%k$r$r?7$7$$L>A0$K%j%M!<%`$7$?>l(B
+$B9g!$2f!9$,$*8_$$$NJQ99$r%^!<%8$9$k$H85$N%U%!%$%kL>$KBP$9$k;d$NJQ99$O!$?7(B
+$B$7$$%U%!%$%kL>$N%U%!%$%k$KGH5Z$9$k!%(B $B!J$3$l$,$G$-$k$N$OEv$?$jA0$H;W$&$+$b(B
+$B$7$l$J$$$,!$<B$N$H$3$m!$A4$F$N%j%S%8%g%s%3%s%H%m!<%k%7%9%F%`$,$G$-$k$o$1(B
+$B$G$O$J$$!%!K(B

-Whereas having changes follow a copy is a feature where you can
-perhaps nod and say ``yes, that might be useful,'' it should be clear
-that having them follow a rename is definitely important.  Without
-this facility, it would simply be too easy for changes to become
-orphaned when files are renamed.
+%Whereas having changes follow a copy is a feature where you can
+%perhaps nod and say ``yes, that might be useful,'' it should be clear
+%that having them follow a rename is definitely important.  Without
+%this facility, it would simply be too easy for changes to become
+%orphaned when files are renamed.
+
+$BJQ99$,%3%T!<$K=>$&5!G=$,M-MQ$G$"$k$3$H$O!$$*$=$i$/MF0W$KF10U$,F@$i$l$k$H(B
+$B$3$m$G$"$k$H;W$o$l$k!%$H$j$o$1%j%M!<%`$KDI=>$9$k5!G=$O$-$o$a$F=EMW$G$"$k(B
+$B$3$H$OL@Gr$G$"$k!%$b$7$3$N5!G=$,$J$1$l$P!$%U%!%$%k$N%j%M!<%`$K$h$C$FJQ99(B
+$B$OMF0W$/9T$->l$r<:$C$F$7$^$&$@$m$&!%(B

 %\subsection{Divergent renames and merging}
 \subsection{$BL>A0$H%^!<%8$NH/;6(B}

-The case of diverging names occurs when two developers start with a
-file---let's call it \filename{foo}---in their respective
-repositories.
+%The case of diverging names occurs when two developers start with a
+%file---let's call it \filename{foo}---in their respective
+%repositories.
+
+2$B?M$N3+H/<T$N%j%]%8%H%j4V$G(B1$B$D$N%U%!%$%k(B ---\filename{foo}$B$H8F$V$3$H$K$9(B
+$B$k(B--- $B$K$D$$$FL>A0$NH/;6$,5/$3$C$?>l9g$K$D$$$F9M$($F$_$h$&!%(B

 \interaction{rename.divergent.clone}
-Anne renames the file to \filename{bar}.
+%Anne renames the file to \filename{bar}.
+$B%"%s$O%U%!%$%k$r(B\filename{bar}$B$H2~L>$7$?!%(B
 \interaction{rename.divergent.rename.anne}
-Meanwhile, Bob renames it to \filename{quux}.
+%Meanwhile, Bob renames it to \filename{quux}.
+$B$=$N4V!$%\%V$OF1$8%U%!%$%k$r(B\filename{quux}$B$H2~L>$7$?!%(B
 \interaction{rename.divergent.rename.bob}

-I like to think of this as a conflict because each developer has
-expressed different intentions about what the file ought to be named.
+%I like to think of this as a conflict because each developer has
+%expressed different intentions about what the file ought to be named.
+
+$B3F!9$N3+H/<T$O%U%!%$%k$,$I$N$h$&$K8F$P$l$k$Y$-$+$K$D$$$F0[$J$C$?0U?^$r;}$C(B
+$B$F$*$j!$$3$l$O%3%s%U%j%/%H$H9M$($i$l$k!%(B

-What do you think should happen when they merge their work?
-Mercurial's actual behaviour is that it always preserves \emph{both}
-names when it merges changesets that contain divergent renames.
+%What do you think should happen when they merge their work?
+%Mercurial's actual behaviour is that it always preserves \emph{both}
+%names when it merges changesets that contain divergent renames.
+%\interaction{rename.divergent.merge}
+
+$BH`$i$,%^!<%8$r9T$C$?:]$K$I$&$J$l$P$h$$$@$m$&$+!)(B Mercurial$B$N<B:]$N5sF0(B
+$B$O!$H/;6$7$?%j%M!<%`$,$"$k%A%'%s%8%;%C%H$r%^!<%8$7$?>l9g$O>o$K(B\emph{$BN>J}(B}$B$N(B
+$BL>A0$rJ]B8$9$k!%(B
 \interaction{rename.divergent.merge}

-Notice that Mercurial does warn about the divergent renames, but it
-leaves it up to you to do something about the divergence after the merge.
+%Notice that Mercurial does warn about the divergent renames, but it
+%leaves it up to you to do something about the divergence after the merge.
+
+Mercurial$B$OL>A0$NH/;6$K$D$$$F7Y9p$9$k$,!$%^!<%88e$bL>A0$NH/;6$N2r7h$O%f!<(B
+$B%6$KG$$;$kE@$KCm0U!%(B

 %\subsection{Convergent renames and merging}
 \subsection{$B%j%M!<%`$H%^!<%8$K$h$k<}B+(B}

-Another kind of rename conflict occurs when two people choose to
-rename different \emph{source} files to the same \emph{destination}.
-In this case, Mercurial runs its normal merge machinery, and lets you
-guide it to a suitable resolution.
+%Another kind of rename conflict occurs when two people choose to
+%rename different \emph{source} files to the same \emph{destination}.
+%In this case, Mercurial runs its normal merge machinery, and lets you
+%guide it to a suitable resolution.
+
+2$B?M$N%f!<%6$,0[$J$k(B\emph{$B%=!<%9(B}$B%U%!%$%k72$rF10l$N(B\emph{$BL\E*(B}$B%U%!%$%k$K%j(B
+$B%M!<%`$9$k$H>WFM$,5/$-$k!%$3$N>l9g!$(BMercurial$B$ODL>o$N%^!<%85!9=$r5/F0$7!$(B
+$B%f!<%6$KE,@Z$J2r7h$rB%$9!%(B

 %\subsection{Other name-related corner cases}
 \subsection{$BL>A0$K4XO"$7$?$$$/$D$+$NLdBj(B}

-Mercurial has a longstanding bug in which it fails to handle a merge
-where one side has a file with a given name, while another has a
-directory with the same name.  This is documented as~\bug{29} .
+%Mercurial has a longstanding bug in which it fails to handle a merge
+%where one side has a file with a given name, while another has a
+%directory with the same name.  This is documented as~\bug{29} .
+%\interaction{issue29.go}
+
+Mercurial$B$K$O!$0lJ}$rL>A0$rM?$($?%U%!%$%k!$$b$&0lJ}$rF1L>$N%G%#%l%/%H%j$H(B
+$B$7$F%^!<%8$r9T$&$H<:GT$9$k%P%0$,0JA0$+$i$"$k!%$3$l$O(B~\bug{29}$B$H$7$F%I%-%e(B
+$B%a%s%H2=$5$l$F$$$k!%(B
 \interaction{issue29.go}

 %\section{Recovering from mistakes}
@@ -398,7 +458,6 @@
 $B$5$l$k!%$^$?(B\hgcmd{revert}$B$O%U%!%$%k$X$N4V0c$C$?JQ99$r>C5n$9$k$N$b;H$($k!%(B

 %It's useful to remember that the \hgcmd{revert} command is useful for
-
 %changes that you have not yet committed.  Once you've committed a
 %change, if you decide it was a mistake, you can still do something
 %about it, though your options may be more limited.
--- a/ja/todo.txt	Fri Jan 09 17:01:40 2009 +0900
+++ b/ja/todo.txt	Fri Jan 09 18:07:12 2009 +0900
@@ -3,11 +3,11 @@
 branch.tex	100%
 collab.tex	100%
 concepts.tex
-daily.tex	2%
+daily.tex	5%
 filenames.tex	100%
 hg_id.tex	noneed
 hgext.tex	100%
-hook.tex	1%
+hook.tex	10%
 intro.tex
 license.tex
 mq-collab.tex   100%