changeset 388:2e072e3d8637

more intro.tex

--- a/ja/intro.tex	Sun Feb 22 00:48:17 2009 +0900
+++ b/ja/intro.tex	Fri Mar 27 17:39:24 2009 +0900
@@ -349,101 +349,130 @@
 %\section{A few of the advantages of distributed revision control}
 \section{$BJ,;6%j%S%8%g%s%3%s%H%m!<%k$NMxE@(B}
 
-Even though distributed revision control tools have for several years
-been as robust and usable as their previous-generation counterparts,
-people using older tools have not yet necessarily woken up to their
-advantages.  There are a number of ways in which distributed tools
-shine relative to centralised ones.
+%Even though distributed revision control tools have for several years
+%been as robust and usable as their previous-generation counterparts,
+%people using older tools have not yet necessarily woken up to their
+%advantages.  There are a number of ways in which distributed tools
+%shine relative to centralised ones.
+
+$BJ,;6%j%S%8%g%s%3%s%H%m!<%k%D!<%k$O$b$&?tG/$bA0$+$iA0@$Be$N%D!<%k$HF1MM$K(B
+$B7xO4$+$DM-MQ$J$b$N$HG'$a$i$l$F$$$k$K$b$+$+$o$i$:!$8E$$%D!<%k$N%f!<%6$?$A(B
+$B$O$=$NMxE@$rCN$i$J$$!%J,;6%D!<%k$,Cf1{=8Cf%D!<%k$h$j$bM%$l$$$F$$$kE@$OB?!9(B
+$B$"$k!%(B
 
-For an individual developer, distributed tools are almost always much
-faster than centralised tools.  This is for a simple reason: a
-centralised tool needs to talk over the network for many common
-operations, because most metadata is stored in a single copy on the
-central server.  A distributed tool stores all of its metadata
-locally.  All else being equal, talking over the network adds overhead
-to a centralised tool.  Don't underestimate the value of a snappy,
-responsive tool: you're going to spend a lot of time interacting with
-your revision control software.
+%For an individual developer, distributed tools are almost always much
+%faster than centralised tools.  This is for a simple reason: a
+%centralised tool needs to talk over the network for many common
+%operations, because most metadata is stored in a single copy on the
+%central server.  A distributed tool stores all of its metadata
+%locally.  All else being equal, talking over the network adds overhead
+%to a centralised tool.  Don't underestimate the value of a snappy,
+%responsive tool: you're going to spend a lot of time interacting with
+%your revision control software.
+
+$B8D?M$N3+H/<T$K$H$C$F$O!$J,;6%D!<%k$O$[$H$s$I$N>l9g!$Cf1{=8Cf%D!<%k$h$j$b(B
+$B9bB.$G$"$k!%$=$NM}M3$O!$Cf1{=8Cf%D!<%k$G$O$[$H$s$I$N%a%?%G!<%?$OCf1{%5!<(B
+$B%P$GC10l%3%T!<$H$7$FJ]4I$5$l$F$*$j!$DL>o$N%*%Z%l!<%7%g%s$NB?$/$r%M%C%H%o!<(B
+$B%/$r7PM3$7$F9T$&I,MW$,$"$k$+$i$@!%J,;6%D!<%k$OA4$F$N%a%?%G!<%?$r%m!<%+%k(B
+$B$KJ]B8$9$k!%$=$NB>$bF1MM$G!$Cf1{=8Cf%D!<%k$O%M%C%H%o!<%/1[$7$NDL?.$K$h$C(B
+$B$F%*!<%P%X%C%I$r@8$8$k!%3+H/Cf!$%j%S%8%g%s%3%s%H%m!<%k%=%U%H%&%'%"$NA`:n(B
+$B$r4vEY$H$J$/9T$&$3$H$r9M$($l$P!$%D!<%k$N6O$+$J%*!<%P%X%C%I$G$b2a>.I>2A$9(B
+$B$Y$-$G$O$J$$!%(B
 
-Distributed tools are indifferent to the vagaries of your server
-infrastructure, again because they replicate metadata to so many
-locations.  If you use a centralised system and your server catches
-fire, you'd better hope that your backup media are reliable, and that
-your last backup was recent and actually worked.  With a distributed
-tool, you have many backups available on every contributor's computer.
+%Distributed tools are indifferent to the vagaries of your server
+%infrastructure, again because they replicate metadata to so many
+%locations.  If you use a centralised system and your server catches
+%fire, you'd better hope that your backup media are reliable, and that
+%your last backup was recent and actually worked.  With a distributed
+%tool, you have many backups available on every contributor's computer.
+
+$BJ,;6%D!<%k$O%a%?%G!<%?$rMM!9$J>l=j$KJ#@=$9$k$?$a!$%5!<%P%$%s%U%i%9%H%i%/(B
+$B%A%c$N>c32$K4X$o$j$J$/F0:n$9$k!%$b$7Cf1{=8Cf%7%9%F%`$r;H$C$F$$$F!$%5!<%P(B
+$B$,2P:R$K$"$C$?$H$7$?$i!$?.Mj$G$-$k%P%C%/%"%C%W%a%G%#%"$K:G6a:n@.$7$?%P%C(B
+$B%/%"%C%W%3%T!<$,;D$C$F$*$j!$$=$l$,$^$H$b$K5!G=$9$k$3$H$r5'$k$3$H$K$J$k!%(B
+$BJ,;6%D!<%k$G$O!$6(NO<T$N%3%s%T%e!<%?$NCf$K?tB?$/$N%P%C%/%"%C%W$,;D$5$l$F(B
+$B$$$k!%(B
 
-The reliability of your network will affect distributed tools far less
-than it will centralised tools.  You can't even use a centralised tool
-without a network connection, except for a few highly constrained
-commands.  With a distributed tool, if your network connection goes
-down while you're working, you may not even notice.  The only thing
-you won't be able to do is talk to repositories on other computers,
-something that is relatively rare compared with local operations.  If
-you have a far-flung team of collaborators, this may be significant.
+%The reliability of your network will affect distributed tools far less
+%than it will centralised tools.  You can't even use a centralised tool
+%without a network connection, except for a few highly constrained
+%commands.  With a distributed tool, if your network connection goes
+%down while you're working, you may not even notice.  The only thing
+%you won't be able to do is talk to repositories on other computers,
+%something that is relatively rare compared with local operations.  If
+%you have a far-flung team of collaborators, this may be significant.
+
+$BJ,;6%D!<%k$G$O!$%M%C%H%o!<%/$N?.Mj@-$NM?$($k1F6A$O=8Cf%D!<%k$KHf$Y$FMZ$+(B
+$B$K>.$5$$!%=8Cf%D!<%k$O!$$$$/$D$+$NBg$-$J@)8B$N$"$k%3%^%s%I$r=|$$$F%M%C%H(B
+$B%o!<%/@\B3$J$7$K;HMQ$G$-$J$$!%J,;6%D!<%k$G$O:n6HCf$K%M%C%H%o!<%/@\B3$,CG(B
+$B$?$l$?$H$7$F$b$=$l$K5$$E$/$3$H$9$i$J$$$@$m$&!%B>$N%3%s%T%e!<%?$N%j%]%8%H(B
+$B%j$H$NDL?.$r9T$&F0:n$N$_$,1F6A$r<u$1$k!%$3$N$h$&$JF0:n$O%m!<%+%k$G$NF0:n(B
+$B$h$jAjBPE*$K>/$J$$$O$:$@!%$3$l$,=EBg$JLdBj$H$J$k$N$O!$9-HO0O$K$o$?$k%A!<(B
+$B%`$G:n6H$r$7$F$$$k>l9g$G$"$m$&!%(B
 
 %\subsection{Advantages for open source projects}
 \subsection{$B%*!<%W%s%=!<%9%W%m%8%'%/%H$G$NMxE@(B}
 
-If you take a shine to an open source project and decide that you
-would like to start hacking on it, and that project uses a distributed
-revision control tool, you are at once a peer with the people who
-consider themselves the ``core'' of that project.  If they publish
-their repositories, you can immediately copy their project history,
-start making changes, and record your work, using the same tools in
-the same ways as insiders.  By contrast, with a centralised tool, you
-must use the software in a ``read only'' mode unless someone grants
-you permission to commit changes to their central server.  Until then,
-you won't be able to record changes, and your local modifications will
-be at risk of corruption any time you try to update your client's view
-of the repository.
+%If you take a shine to an open source project and decide that you
+%would like to start hacking on it, and that project uses a distributed
+%revision control tool, you are at once a peer with the people who
+%consider themselves the ``core'' of that project.  If they publish
+%their repositories, you can immediately copy their project history,
+%start making changes, and record your work, using the same tools in
+%the same ways as insiders.  By contrast, with a centralised tool, you
+%must use the software in a ``read only'' mode unless someone grants
+%you permission to commit changes to their central server.  Until then,
+%you won't be able to record changes, and your local modifications will
+%be at risk of corruption any time you try to update your client's view
+%of the repository.
 
 %\subsubsection{The forking non-problem}
 \subsubsection{$BLdBj$J$/%U%)!<%/2DG=(B}
 
-It has been suggested that distributed revision control tools pose
-some sort of risk to open source projects because they make it easy to
-``fork'' the development of a project.  A fork happens when there are
-differences in opinion or attitude between groups of developers that
-cause them to decide that they can't work together any longer.  Each
-side takes a more or less complete copy of the project's source code,
-and goes off in its own direction.
+%It has been suggested that distributed revision control tools pose
+%some sort of risk to open source projects because they make it easy to
+%``fork'' the development of a project.  A fork happens when there are
+%differences in opinion or attitude between groups of developers that
+%cause them to decide that they can't work together any longer.  Each
+%side takes a more or less complete copy of the project's source code,
+%and goes off in its own direction.
 
-Sometimes the camps in a fork decide to reconcile their differences.
-With a centralised revision control system, the \emph{technical}
-process of reconciliation is painful, and has to be performed largely
-by hand.  You have to decide whose revision history is going to
-``win'', and graft the other team's changes into the tree somehow.
-This usually loses some or all of one side's revision history.
+%Sometimes the camps in a fork decide to reconcile their differences.
+%With a centralised revision control system, the \emph{technical}
+%process of reconciliation is painful, and has to be performed largely
+%by hand.  You have to decide whose revision history is going to
+%``win'', and graft the other team's changes into the tree somehow.
+%This usually loses some or all of one side's revision history.
 
-What distributed tools do with respect to forking is they make forking
-the \emph{only} way to develop a project.  Every single change that
-you make is potentially a fork point.  The great strength of this
-approach is that a distributed revision control tool has to be really
-good at \emph{merging} forks, because forks are absolutely
-fundamental: they happen all the time.  
+%What distributed tools do with respect to forking is they make forking
+%the \emph{only} way to develop a project.  Every single change that
+%you make is potentially a fork point.  The great strength of this
+%approach is that a distributed revision control tool has to be really
+%good at \emph{merging} forks, because forks are absolutely
+%fundamental: they happen all the time.
 
-If every piece of work that everybody does, all the time, is framed in
-terms of forking and merging, then what the open source world refers
-to as a ``fork'' becomes \emph{purely} a social issue.  If anything,
-distributed tools \emph{lower} the likelihood of a fork:
-\begin{itemize}
-\item They eliminate the social distinction that centralised tools
-  impose: that between insiders (people with commit access) and
-  outsiders (people without).
-\item They make it easier to reconcile after a social fork, because
-  all that's involved from the perspective of the revision control
-  software is just another merge.
-\end{itemize}
+%If every piece of work that everybody does, all the time, is framed in
+%terms of forking and merging, then what the open source world refers
+%to as a ``fork'' becomes \emph{purely} a social issue.  If anything,
+%distributed tools \emph{lower} the likelihood of a fork:
+%\begin{itemize}
+%\item They eliminate the social distinction that centralised tools
+%  impose: that between insiders (people with commit access) and
+%  outsiders (people without).
+%\item They make it easier to reconcile after a social fork, because
+%  all that's involved from the perspective of the revision control
+%  software is just another merge.
+%\end{itemize}
 
-Some people resist distributed tools because they want to retain tight
-control over their projects, and they believe that centralised tools
-give them this control.  However, if you're of this belief, and you
-publish your CVS or Subversion repositories publically, there are
-plenty of tools available that can pull out your entire project's
-history (albeit slowly) and recreate it somewhere that you don't
-control.  So while your control in this case is illusory, you are
-forgoing the ability to fluidly collaborate with whatever people feel
-compelled to mirror and fork your history.
+%Some people resist distributed tools because they want to retain tight
+%control over their projects, and they believe that centralised tools
+%give them this control.  However, if you're of this belief, and you
+%publish your CVS or Subversion repositories publically, there are
+%plenty of tools available that can pull out your entire project's
+%history (albeit slowly) and recreate it somewhere that you don't
+%control.  So while your control in this case is illusory, you are
+%forgoing the ability to fluidly collaborate with whatever people feel
+%compelled to mirror and fork your history.
 
 %\subsection{Advantages for commercial projects}
 \subsection{$B>&MQ%W%m%8%'%/%H$G$NMxE@(B}
@@ -517,10 +546,14 @@
 %\section{Mercurial compared with other tools}
 \section{Mercurial$B$HB>$N%D!<%k$NHf3S(B}
 
-Before you read on, please understand that this section necessarily
-reflects my own experiences, interests, and (dare I say it) biases.  I
-have used every one of the revision control tools listed below, in
-most cases for several years at a time.
+%Before you read on, please understand that this section necessarily
+%reflects my own experiences, interests, and (dare I say it) biases.  I
+%have used every one of the revision control tools listed below, in
+%most cases for several years at a time.
+
+$B$3$N@a$rFI$`A0$K!$$3$l$OI.<T<+?H$NBN83$H6=L#!$$=$7$F!J4:$($F8@$($P!K%P%$(B
+$B%"%9$,$+$+$C$F$$$k$3$H$rM}2r$7$FM_$7$$!%I.<T$O2<5-$N%j%S%8%g%s%3%s%H%m!<(B
+$B%k%D!<%k$N$9$Y$F$r;HMQ$7$?$3$H$,$"$j!$$=$N;HMQ4|4V$OB?$/$N>l9g?tG/$K5Z$V!%(B
 
 
 \subsection{Subversion}
@@ -590,37 +623,64 @@
 
 \subsection{Git}
 
-Git is a distributed revision control tool that was developed for
-managing the Linux kernel source tree.  Like Mercurial, its early
-design was somewhat influenced by Monotone.
+%Git is a distributed revision control tool that was developed for
+%managing the Linux kernel source tree.  Like Mercurial, its early
+%design was somewhat influenced by Monotone.
+
+Git$B$O(BLinux$B%+!<%M%k$N%=!<%9%D%j!<$r07$&$?$a$K3+H/$5$l$?J,;6%j%S%8%g%s%3%s(B
+$B%H%m!<%k%D!<%k$G$"$k!%(B Mercurial$BF1MM!$$=$N=i4|$N%G%6%$%s$OB?>/(BMonotone$B$K(B
+$B1F6A$r<u$1$F$$$k!%(B
+
+%Git has a very large command set, with version~1.5.0 providing~139
+%individual commands.  It has something of a reputation for being
+%difficult to learn.  Compared to Git, Mercurial has a strong focus on
+%simplicity.
 
-Git has a very large command set, with version~1.5.0 providing~139
-individual commands.  It has something of a reputation for being
-difficult to learn.  Compared to Git, Mercurial has a strong focus on
-simplicity.
+Git$B$OHs>o$KBg5,LO$J%3%^%s%I%;%C%H$r;}$C$F$$$k!%(Bversion~1.5.0$B$G$O(B~139$B$K$b(B
+$B5Z$V%3%^%s%I$,MQ0U$5$l$F$$$k!%$3$N$?$a!$(BGit$B$O$7$P$7$P=,F@$7$E$i$$$H$$$&(B
+$BI>H=$5$l$F$$$k!%(BMercurial$B$O(BGit$B$HHf$Y$k$H4J7i$5$K6/$/%U%)!<%+%9$7$F$$$k!%(B
 
-In terms of performance, Git is extremely fast.  In several cases, it
-is faster than Mercurial, at least on Linux, while Mercurial performs
-better on other operations.  However, on Windows, the performance and
-general level of support that Git provides is, at the time of writing,
-far behind that of Mercurial.
+%In terms of performance, Git is extremely fast.  In several cases, it
+%is faster than Mercurial, at least on Linux, while Mercurial performs
+%better on other operations.  However, on Windows, the performance and
+%general level of support that Git provides is, at the time of writing,
+%far behind that of Mercurial.
+
+$B@-G=$K4X$7$F$O!$(BGit$B$O6K$a$F9bB.$G$"$k!%(BLinux$B4D6-$G$N%F%9%H$G$O!$$$$/$D$+(B
+$B$NA`:n$O(BGit$B$O(BMercurial$B$h$j$b9bB.$G$"$C$?!%$7$+$7(BWindows$B4D6-$G$O!$$3$NK\$N(B
+$B<9I.;~E@$G$O!$@-G=$d(BGit$B$NDs6!$9$k5!G=$O(BMercurial$B$KBg$-$/Nt$C$?!%(B
 
-While a Mercurial repository needs no maintenance, a Git repository
-requires frequent manual ``repacks'' of its metadata.  Without these,
-performance degrades, while space usage grows rapidly.  A server that
-contains many Git repositories that are not rigorously and frequently
-repacked will become heavily disk-bound during backups, and there have
-been instances of daily backups taking far longer than~24 hours as a
-result.  A freshly packed Git repository is slightly smaller than a
-Mercurial repository, but an unpacked repository is several orders of
-magnitude larger.
+%While a Mercurial repository needs no maintenance, a Git repository
+%requires frequent manual ``repacks'' of its metadata.  Without these,
+%performance degrades, while space usage grows rapidly.  A server that
+%contains many Git repositories that are not rigorously and frequently
+%repacked will become heavily disk-bound during backups, and there have
+%been instances of daily backups taking far longer than~24 hours as a
+%result.  A freshly packed Git repository is slightly smaller than a
+%Mercurial repository, but an unpacked repository is several orders of
+%magnitude larger.
 
-The core of Git is written in C.  Many Git commands are implemented as
-shell or Perl scripts, and the quality of these scripts varies widely.
-I have encountered several instances where scripts charged along
-blindly in the presence of errors that should have been fatal.
+Mercurial$B%j%]%8%H%j$O%a%s%F%J%s%9$rI,MW$H$7$J$$$,!$(BGit$B%j%]%8%H%j$O$7$P$7(B
+$B$P<jF0$G%a%?%G!<%?$N(B``repacks''$B$,I,MW$H$J$k!%$3$l$r9T$o$J$$>l9g!$@-G=$ONt(B
+$B2=$7!$I,MW$J5-21NN0h$b5^B.$K3HBg$9$k!%(BGit$B%j%]%8%H%j$r5,B'@5$7$/IQHK$K(B
+repack$B$7$J$$%5!<%P$G$O%P%C%/%"%C%W$N:]$K%G%#%9%/;HMQ$,6K$a$FB?$/$J$j!$7k(B
+$B2L$H$7$FKhF|$N%P%C%/%"%C%W$K(B~24$B;~4V0J>e$rHq$d$9$3$H$K$J$k!%(B
+$B?75,$K(Bpack$B$5$l$?(BGit$B%j%]%8%H%j$O(BMercurial$B%j%]%8%H%j$h$j$d$d>.$5$$(B
+$B$,!$(Bunpack$B>uBV$N(BGit$B%j%]%8%H%j$O?tCJBg$-$/$J$k!%(B
 
-Mercurial can import revision history from a Git repository.
+%The core of Git is written in C.  Many Git commands are implemented as
+%shell or Perl scripts, and the quality of these scripts varies widely.
+%I have encountered several instances where scripts charged along
+%blindly in the presence of errors that should have been fatal.
+
+Git$B$N%3%"$O(BC$B$G=q$+$l$F$$$k!%(BGit$B%3%^%s%I$NB?$/$O%7%'%k$d(BPerl$B$N%9%/%j%W%H$H(B
+$B$7$F<BAu$5$l$F$*$j!$$=$l$i$N%9%/%j%W%H$NIJ<A$OMM!9$G$"$k!%?tEY$K$o$?$C$F(B
+$BCWL?E*$J%(%i!<$,$"$k$K$b$+$+$o$i$:!$%9%/%j%W%H$,LULGK!$KF0:n$9$k$3$H$rBN(B
+$B83$7$?!%(B
+
+%Mercurial can import revision history from a Git repository.
+
+Mercurial$B$O(BGit$B%j%]%8%H%j$+$i%j%S%8%g%sMzNr$r%$%s%]!<%H$9$k$3$H$,$G$-$k!%(B
 
 
 \subsection{CVS}
@@ -664,47 +724,75 @@
 %\subsection{Commercial tools}
 \subsection{$B>&MQ%D!<%k(B}
 
-Perforce has a centralised client/server architecture, with no
-client-side caching of any data.  Unlike modern revision control
-tools, Perforce requires that a user run a command to inform the
-server about every file they intend to edit.
+%Perforce has a centralised client/server architecture, with no
+%client-side caching of any data.  Unlike modern revision control
+%tools, Perforce requires that a user run a command to inform the
+%server about every file they intend to edit.
+
+Perforce$B$O=8Cf7?$N%/%i%$%"%s%H!&%5!<%P%"!<%-%F%/%A%c$r;}$A!$$$$+$J$k%G!<(B
+$B%?$b%/%i%$%"%s%HB&$G%-%c%C%7%e$7$J$$!%8=:_$N%j%S%8%g%s%3%s%H%m!<%k%D!<%k(B
+$B$H$3$H$J$j!$(BPerforce$B$G$O%f!<%6$,$I$N%U%!%$%k$rJT=8$9$k$N$+%5!<%P$KCN$i$;(B
+$B$k%3%^%s%I$r<B9T$9$kI,MW$,$"$k!%(B
 
-The performance of Perforce is quite good for small teams, but it
-falls off rapidly as the number of users grows beyond a few dozen.
-Modestly large Perforce installations require the deployment of
-proxies to cope with the load their users generate.
+%The performance of Perforce is quite good for small teams, but it
+%falls off rapidly as the number of users grows beyond a few dozen.
+%Modestly large Perforce installations require the deployment of
+%proxies to cope with the load their users generate.
 
+Perforce$B$N@-G=$O!$>.5,LO$J%A!<%`$G$N:n6H$K$*$$$F$O$+$J$jNI$$!%$7$+$7%f!<(B
+$B%6?t$,?t%@!<%90J>e$KA}2C$9$k$K=>$C$F!$5^7c$K0-$/$J$C$F$$$/!%$+$J$jBg5,LO(B
+$B$J(BPerforce$B4D6-$G$O!$%f!<%6$NA`:n$K$h$kIi2Y$r7Z8:$9$k$?$a$N%W%m%-%7!<$,I,(B
+$BMW$K$J$k!%(B
 
 %\subsection{Choosing a revision control tool}
 \subsection{$B%j%S%8%g%s%3%s%H%m!<%k%D!<%k$rA*$V(B}
 
-With the exception of CVS, all of the tools listed above have unique
-strengths that suit them to particular styles of work.  There is no
-single revision control tool that is best in all situations.
+%With the exception of CVS, all of the tools listed above have unique
+%strengths that suit them to particular styles of work.  There is no
+%single revision control tool that is best in all situations.
+
+CVS$B$r=|$$$F!$>e5-$N%D!<%k$OFCDj$N:n6H%9%?%$%k$K9g$C$?8GM-$N6/$_$r;}$C$F$$(B
+$B$k!%$9$Y$F$N>u67$G%Y%9%H$G$"$k%D!<%k$H$$$&$b$N$OB8:_$7$J$$!%(B
 
-As an example, Subversion is a good choice for working with frequently
-edited binary files, due to its centralised nature and support for
-file locking.  If you're averse to the command line, it currently has
-better GUI support than other free revision control tools.  However,
-its poor merging is a substantial liability for busy projects with
-overlapping development.
+%As an example, Subversion is a good choice for working with frequently
+%edited binary files, due to its centralised nature and support for
+%file locking.  If you're averse to the command line, it currently has
+%better GUI support than other free revision control tools.  However,
+%its poor merging is a substantial liability for busy projects with
+%overlapping development.
 
-I personally find Mercurial's properties of simplicity, performance,
-and good merge support to be a compelling combination that has served
-me well for several years.
+$BNc$($P!$IQHK$KJQ99$5$l$k%P%$%J%j%U%!%$%k$r07$&>l9g$O(BSubverrsion$B$rA*$V$N$,(B
+$BNI$$!%(BSubversion$B$N=8Cf7?$N@-<A$H%U%!%$%k%m%C%/$N%5%]!<%H$O%P%$%J%j%U%!%$(B
+$B%k$N<h$j07$$$KE,$7$F$$$k!%%3%^%s%I%i%$%s$,7y$$$J$i$P!$B>$N%U%j!<%j%S%8%g(B
+$B%s4IM}%D!<%k$h$j$bM%$l$?(BGUI$B%5%]!<%H$,$"$k!%$7$+$7%^!<%85!9=$N<e$5$OF1;~$K(B
+$BJB9T$7$?3+H/$G$O>/$J$+$i$LLdBj$H$J$j$&$k!%(B
 
+%I personally find Mercurial's properties of simplicity, performance,
+%and good merge support to be a compelling combination that has served
+%me well for several years.
+
+$B8D?ME*$K$O!$?tG/$K$o$?$C$F!$(BMercurial$B$N4J7i$5!$@-G=!$M%$l$?%^!<%8%5%]!<%H(B
+$B$O!$>h$j49$($k$KCM$9$kAH9g$;$@$H46$8$F$$$k!%(B
 
 %\section{Switching from another tool to Mercurial}
 \section{$BB>$N%D!<%k$+$i(BMercurial$B$X$N0\9T(B}
 
-Mercurial is bundled with an extension named \hgext{convert}, which
-can incrementally import revision history from several other revision
-control tools.  By ``incremental'', I mean that you can convert all of
-a project's history to date in one go, then rerun the conversion later
-to obtain new changes that happened after the initial conversion.
+%Mercurial is bundled with an extension named \hgext{convert}, which
+%can incrementally import revision history from several other revision
+%control tools.  By ``incremental'', I mean that you can convert all of
+%a project's history to date in one go, then rerun the conversion later
+%to obtain new changes that happened after the initial conversion.
 
-The revision control tools supported by \hgext{convert} are as
-follows:
+Mercurial$B$K$O(B\hgext{convert}$B$H$$$&3HD%$,F1:-$5$l$F$$$k!%$3$N3HD%$O%j%S%8%g(B
+$B%sMzNr$rB>$N%j%S%8%g%s%3%s%H%m!<%k%D!<%k$+$i%$%s%/%j%a%s%?%k$K%$%s%]!<%H(B
+$B$9$k!%!V%$%s%/%j%a%s%?%k!W$H$$$&$N$O!$$^$:%W%m%8%'%/%H$NMzNr$9$Y$F$rJQ49(B
+$B$7$?8e$G!$85$N%j%]%8%H%j$K5/$-$?JQ99$r$5$i$KJQ49$7$F<h$j9~$a$k$H$$$&0UL#(B
+$B$G$"$k!%(B
+
+%The revision control tools supported by \hgext{convert} are as
+%follows:
+
+\hgext{convert}$B$O<!$N%j%S%8%g%s%3%s%H%m!<%k%D!<%k$r%5%]!<%H$9$k(B:
 \begin{itemize}
 \item Subversion
 \item CVS
@@ -712,17 +800,25 @@
 \item Darcs
 \end{itemize}
 
-In addition, \hgext{convert} can export changes from Mercurial to
-Subversion.  This makes it possible to try Subversion and Mercurial in
-parallel before committing to a switchover, without risking the loss
-of any work.
+%In addition, \hgext{convert} can export changes from Mercurial to
+%Subversion.  This makes it possible to try Subversion and Mercurial in
+%parallel before committing to a switchover, without risking the loss
+%of any work.
+
+$B2C$($F!$(B\hgext{convert}$B$O(BMercurial$B$+$i(BSubversion$B$KJQ99$r%(%/%9%]!<%H$9$k(B
+$B$3$H$,$G$-$k!%$3$l$K$h$j!$(BSubversion$B$+$i(BMercurial$B$K@ZBX$($kA0$K!$9T$C$?:n(B
+$B6H$N7k2L$r<:$&$3$H$J$/!$N><T$rJB9T$7$F;n$9$3$H$,$G$-$k!%(B
 
-The \hgxcmd{conver}{convert} command is easy to use.  Simply point it
-at the path or URL of the source repository, optionally give it the
-name of the destination repository, and it will start working.  After
-the initial conversion, just run the same command again to import new
-changes.
+%The \hgxcmd{conver}{convert} command is easy to use.  Simply point it
+%at the path or URL of the source repository, optionally give it the
+%name of the destination repository, and it will start working.  After
+%the initial conversion, just run the same command again to import new
+%changes.
 
+\hgxcmd{conver}{convert}$B%3%^%s%I$r;H$&$N$O$?$d$9$$!%C1$K%=!<%9%j%]%8%H%j(B
+$B$N%Q%9$d(BURL$B$rEO$9$@$1$G!$;HMQ2DG=$J%j%]%8%H%j$r:n@.$9$k!%$^$?!$%*%W%7%g%s(B
+$B$GJQ498e$N%j%]%8%H%j$NL>A0$rEO$9$3$H$b$G$-$k!%:G=i$NJQ498e!$F1$8%3%^%s%I(B
+$B$r:F$S<B9T$9$k$H?7$7$$JQ99$r<h$j9~$`$3$H$,$G$-$k!%(B
 
 %%% Local Variables:
 %%% mode: yatex