annotate ja/intro.tex @ 835:8a3041e6f3cb

reflect comments by Hiroshi Someya.

%\chapter{Introduction}
\chapter{$BF3F~(B}
\label{chap:intro}

%\section{About revision control}
\section{$B%j%S%8%g%s%3%s%H%m!<%k(B}

%Revision control is the process of managing multiple versions of a
%piece of information.  In its simplest form, this is something that
%many people do by hand: every time you modify a file, save it under a
%new name that contains a number, each one higher than the number of
%the preceding version.

$B%j%S%8%g%s%3%s%H%m!<%k$H$O!$J#?t$N%P!<%8%g%s$N>pJs$r4IM}$9$k%W%m%;%9$G$"(B
$B$k!%:G$bC1=c$JJ}K!$O!$%U%!%$%k$rJQ99$7$?$i!$$=$l$^$G$N%P!<%8%g%s$h$j$bBg(B
$B$-$J?t;z$r4^$`?7$?$JL>A0$G%;!<%V$r9T$&$J$I$NJ}K!$GA4$F<j$G9T$&$3$H$G$"$k!%(B

%Manually managing multiple versions of even a single file is an
%error-prone task, though, so software tools to help automate this
%process have long been available.  The earliest automated revision
%control tools were intended to help a single user to manage revisions
%of a single file.  Over the past few decades, the scope of revision
%control tools has expanded greatly; they now manage multiple files,
%and help multiple people to work together.  The best modern revision
%control tools have no problem coping with thousands of people working
%together on projects that consist of hundreds of thousands of files.

$B$?$C$?0l$D$N%U%!%$%k$KBP$7$F$b!$J#?t$N%P!<%8%g%s$r<j$G4IM}$9$k$3$H$O4V0c(B
$B$$$r5/$3$70W$$:n6H$G!$$3$N%W%m%;%9$r<+F02=$9$k%=%U%H%&%'%"%D!<%k$,$+$J$j(B
$B$N@N$+$iDs6!$5$l$F$-$?!%:G=i$N<+F02=$5$l$?%j%S%8%g%s%3%s%H%m!<%k%D!<%k(B
$B$O!$0l?M$N%f!<%6$rBP>]$H$7$F!$(B1$B$D$N%U%!%$%k$N%j%S%8%g%s$r4IM}$9$k$?$a$K:n(B
$B$i$l$?!%?t==G/$,7P$A!$%j%S%8%g%s%3%s%H%m!<%k$N<h$j07$&%9%3!<%W$OBg$$$K3H(B
$BBg$7$?!%:#$G$OJ#?t?M$K$h$kJ#?t%U%!%$%k$NJT=8$r$b4IM}$9$k$3$H$,$G$-$k!%8=(B
$BBe$N:G9b$N%j%S%8%g%s4IM}%D!<%k$O?t@i?M$K$h$k!$?t==K|8D$N%U%!%$%k$rMJ$9$k(B
$B%W%m%8%'%/%H$K$bBP1~$9$k!%(B

%\subsection{Why use revision control?}
\subsection{$B$J$<%j%S%8%g%s%3%s%H%m!<%k$r;H$&$N$+(B?}

%There are a number of reasons why you or your team might want to use
%an automated revision control tool for a project.
$B%W%m%8%'%/%H$N$?$a$K<+F02=$5$l$?%j%S%8%g%s%3%s%H%m!<%k%D!<%k$r;H$*$&$H9M(B
$B$($kM}M3$O?tB?$/$"$k!%(B
\begin{itemize}
%\item It will track the history and evolution of your project, so you
%  don't have to.  For every change, you'll have a log of \emph{who}
%  made it; \emph{why} they made it; \emph{when} they made it; and
%  \emph{what} the change was.
 \item $B%j%S%8%g%s4IM}%D!<%k$O!$%W%m%8%'%/%H$NMzNr$H?J2=$r5-O?$9$k$?$a!$<+(B
       $BJ,<+?H$G5-O?$9$kI,MW$,$J$$!%A4$F$NJQ99$KBP$7$F(B\emph{$BC/$,(B}\emph{$B2?(B
       $B$N$?$a$K(B}\emph{$B$$$D(B}\emph{$B2?$r(B}$BJQ99$7$?$N$+$,5-O?$5$l$k!%(B
%\item When you're working with other people, revision control software
%  makes it easier for you to collaborate.  For example, when people
%  more or less simultaneously make potentially incompatible changes,
%  the software will help you to identify and resolve those conflicts.
 \item $B%j%S%8%g%s%3%s%H%m!<%k%=%U%H%&%'%"$OB>$N?M$H$N6&F1:n6H$r=u$1$k!%Nc(B
       $B$($P!$J#?t$N%f!<%6$,F1;~$K8_49@-$N$J$$JQ99$r9T$C$?>l9g!$%=%U%H%&%'(B
       $B%"$N;Y1g$G%3%s%U%j%/%H$rFCDj$72r7h$9$k$3$H$,$G$-$k!%(B
%\item It can help you to recover from mistakes.  If you make a change
%  that later turns out to be in error, you can revert to an earlier
%  version of one or more files.  In fact, a \emph{really} good
%  revision control tool will even help you to efficiently figure out
%  exactly when a problem was introduced (see
%  section~\ref{sec:undo:bisect} for details).
 \item $B%j%S%8%g%s4IM}%D!<%k$OHH$7$?%_%9$+$i$N2sI|$r=u$1$k!%2C$($?JQ99$,8e(B
$B$G4V0c$$$G$"$C$?$HJ,$+$C$?;~!$(B1$B$D$^$?$OJ#?t$N%U%!%$%k$X$NJQ99$rGK4~$9$k$3(B
$B$H$,$G$-$k!%<B:]$N$H$3$m!$(B\emph{$B??$K(B}$BM%$l$?%j%S%8%g%s%3%s%H%m!<%k%D!<%k$O(B
$BJ6$l9~$s$@LdBj$rFCDj$9$k$N$r;Y1g$9$k5!G=$r;}$D!%!J>\:Y$K$D$$$F(B
$B$O(B~\ref{sec:undo:bisect}$B@a$r;2>H!%!K(B
%\item It will help you to work simultaneously on, and manage the drift
%  between, multiple versions of your project.
 \item $B%j%S%8%g%s4IM}%D!<%k$O!$%W%m%8%'%/%H$NJ#?t$N%P!<%8%g%s$G$NF1;~:n(B
       $B6H$d!$%j%S%8%g%s4V$N0\9T$r;Y1g$9$k!%(B
\end{itemize}
%Most of these reasons are equally valid---at least in theory---whether
%you're working on a project by yourself, or with a hundred other
%people.
$B$3$l$i$NM}M3$NB?$/$O<+J,<+?H$N%W%m%8%'%/%H$G:n6H$7$F$$$F$b!$(B100$B?M$N6&F1:n(B
$B6H<T$H:n6H$7$F$$$F$b>/$J$/$H$bM}O@E*$K$OEy$7$/M-0U$G$"$k!%(B

%A key question about the practicality of revision control at these two
%different scales (``lone hacker'' and ``huge team'') is how its
%\emph{benefits} compare to its \emph{costs}.  A revision control tool
%that's difficult to understand or use is going to impose a high cost.

$B%j%S%8%g%s%3%s%H%m!<%k$,<BMQE*$G$"$k$+$I$&$+H=CG$9$k80$O!$$5$^$6$^$J3+H/(B
$B%9%1!<%k!J(B``1$B?M$N%O%C%+!<(B''$B%l%Y%k$+$i(B``$BBg5,LO%A!<%`(B''$B%l%Y%k$^$G!K$K$*$$(B
$B$F!$;YJ'$&%3%9%H$KBP$7$F$I$l$@$18zG=$,F@$i$l$k$+$H$$$&$3$H$G$"$k!%M}2r$d(B
$B;HMQ$,:$Fq$J%j%S%8%g%s%3%s%H%m!<%k%D!<%k$O9b$$%3%9%H$r2]$9$3$H$K$J$k!%(B

%A five-hundred-person project is likely to collapse under its own
%weight almost immediately without a revision control tool and process.
%In this case, the cost of using revision control might hardly seem
%worth considering, since \emph{without} it, failure is almost
%guaranteed.

500$B?M$+$i$J$k%W%m%8%'%/%H$G$O!$%j%S%8%g%s%3%s%H%m!<%k%D!<%k$J$7$G$OKX$s$I(B
$BN)$A9T$+$J$$!%$3$N>l9g!$%j%S%8%g%s%3%s%H%m!<%k$J$7$G$OL@$i$+$K<:GT$9$k$?(B
$B$a!$%j%S%8%g%s%3%s%H%m!<%k$r9T$&%3%9%H$OFC$KLdBj$H$O$J$i$J$$!%(B%xxx

%On the other hand, a one-person ``quick hack'' might seem like a poor
%place to use a revision control tool, because surely the cost of using
%one must be close to the overall cost of the project.  Right?

$B0lJ}!$(B1$B?M$N3+H/<T$K$h$k(B``$B%/%$%C%/%O%C%/(B''$B$O%j%S%8%g%s%3%s%H%m!<%k%D!<%k(B
$B$r;H$&$K$O$"$^$j$U$5$o$7$/$J$$!%$J$<$J$i!$%D!<%k$r;H$&%3%9%H$,$[$\%W%m%8%'(B
$B%/%H$N%3%9%H$=$N$b$N$G$"$k$+$i$@!%$3$l$O@5$7$$$@$m$&$+!)(B

%Mercurial uniquely supports \emph{both} of these scales of
%development.  You can learn the basics in just a few minutes, and due
%to its low overhead, you can apply revision control to the smallest of
%projects with ease.  Its simplicity means you won't have a lot of
%abstruse concepts or command sequences competing for mental space with
%whatever you're \emph{really} trying to do.  At the same time,
%Mercurial's high performance and peer-to-peer nature let you scale
%painlessly to handle large projects.

Mercurial$B$O$3$l$i$N3+H/%9%1!<%k$NN>J}$r%5%]!<%H$7$F$$$k!%4pACE*$J;HMQK!$O(B
$B?tJ,$G3X$V$3$H$,$G$-!$%j%S%8%g%s%3%s%H%m!<%k$r:G>.5,LO$N%W%m%8%'%/%H$K4J(B
$BC1$K<h$jF~$l$k$3$H$,$G$-$k!%C1=c$G$"$k$?$a!$Fq2r$J%3%s%;%W%H$d%3%^%s%I%7!<(B
$B%1%s%9$K0U<1$NB?$/$r@j$a$i$l!$K\Ev$K$d$j$?$$$3$H$,AB$+$K$J$k$3$H$b$J$$!%(B
$B$^$?F1;~$K(BMercurial$B$N@-G=$N9b$5$d!$%T%"%D!<%T%"$N@-<A$N$?$a$K!$Bg5,LO%W%m(B
$B%8%'%/%H$K$b6lO+$9$k;v$J$/%9%1!<%k$9$k$3$H$,$G$-$k!%(B

%No revision control tool can rescue a poorly run project, but a good
%choice of tools can make a huge difference to the fluidity with which
%you can work on a project.

$B$*AFKv$J%W%m%8%'%/%H$r5_:Q$9$k$h$&$J%j%S%8%g%s%3%s%H%m!<%k$OB8:_$7$J$$(B
$B$,!$NI$$%D!<%k$NA*Br$O!$:n6H$9$k%W%m%8%'%/%H$N7x<B$5$KBg$-$J:9$r$b$?$i$9!%(B

%\subsection{The many names of revision control}
\subsection{$BMM!9$J%j%S%8%g%s%3%s%H%m!<%k(B}

%Revision control is a diverse field, so much so that it doesn't
%actually have a single name or acronym.  Here are a few of the more
%common names and acronyms you'll encounter:
$B%j%S%8%g%s%3%s%H%m!<%k$OBg$-$JI}$r$b$DJ,Ln$G$"$j!$$=$N$?$aB?$/$N8F$SL>$H(B
$B$=$NC;=L7A$,CN$i$l$F$$$k!'(B
\begin{itemize}
\item $B%j%S%8%g%s%3%s%H%m!<%k(B (Revision control (RCS))
\item $B%=%U%H%&%'%"@_Dj%^%M%8%a%s%H$^$?$O@_Dj%^%M%8%a%s%H(B (Software configuration management (SCM), or configuration management)
\item $B%=!<%9%3!<%I%^%M%8%a%s%H(B (Source code management)
\item $B%=!<%9%3!<%I%3%s%H%m!<%k$^$?$O%=!<%9%3%s%H%m!<%k(B (Source code control, or source control)
\item $B%P!<%8%g%s%3%s%H%m!<%k(B (Version control (VCS))
\end{itemize}
%Some people claim that these terms actually have different meanings,
%but in practice they overlap so much that there's no agreed or even
%useful way to tease them apart.
$B$3$l$i$NMQ8l$O3F!90c$&0UL#$r;}$D$N$@$H<gD%$9$k?M!9$b$$$k!%$7$+$7<B<AE*$K(B
$B$O$3$l$i$O8_$$$KBg$-$/=E$J$C$F$*$j!$$o$6$o$66hJL$9$k$3$H$O0lHLE*$G$J$/!$(B
$B$^$?M-MQ$G$b$J$$!%(B

%\section{A short history of revision control}
\section{$B%j%S%8%g%s%3%s%H%m!<%k$NNr;K(B}

%The best known of the old-time revision control tools is SCCS (Source
%Code Control System), which Marc Rochkind wrote at Bell Labs, in the
%early 1970s.  SCCS operated on individual files, and required every
%person working on a project to have access to a shared workspace on a
%single system.  Only one person could modify a file at any time;
%arbitration for access to files was via locks.  It was common for
%people to lock files, and later forget to unlock them, preventing
%anyone else from modifying those files without the help of an
%administrator.

$B:G$bCN$i$l$F$$$k8E$$%j%S%8%g%s%3%s%H%m!<%k%D!<%k$O!$(BMarc Rochkind$B$,(B1970$BG/(B
$BBe=iF,$K(BBell$B8&5f=j$G=q$$$?(BSCCS (Source Code Control System)$B$G$"$k!%(B SCCS
$B$O8D!9$N%U%!%$%k$KBP$7$FF0:n$7!$%W%m%8%'%/%H$N6&F1:n6H<T$K$OF10l%^%7%s>e(B
$B$N6&M-%o!<%/%9%Z!<%9$X$N%"%/%;%9$,I,MW$G$"$C$?!%%U%!%$%k$X$N%"%/%;%9$ND4(B
$BDd$O%m%C%/$K$h$C$F9T$o$l!$$"$k%U%!%$%k$rJQ99$G$-$k$N$O>o$K0l?M$N%f!<%6$@(B
$B$1$G$"$C$?!%%U%!%$%k$r%m%C%/$7$?8e!$%m%C%/$N2r=|$rK:$l$k$3$H$OF|>oE*$K$"(B
$B$j!$$3$&$J$k$H4IM}<T$N=u$1$J$7$KB>$N3+H/<T$,%U%!%$%k$rJQ99$9$k$3$H$O$G$-(B
$B$J$+$C$?!%(B

%Walter Tichy developed a free alternative to SCCS in the early 1980s;
%he called his program RCS (Revison Control System).  Like SCCS, RCS
%required developers to work in a single shared workspace, and to lock
%files to prevent multiple people from modifying them simultaneously.

Walter Tichy$B$O!$(B1980$BG/Be=iF,$K(BSCCS$B$NBeBX$H$J$k%U%j!<$N%P!<%8%g%s%3%s%H%m!<(B
$B%k%D!<%k$r3+H/$7$?!%H`$O<+$i$N%7%9%F%`$r(BRCS (Revison Control System)$B$H8F(B
$B$s$@!%(BSCCS$BF1MM!$(BRCS$B$O3+H/<T$?$A$KC10l$N6&M-%o!<%/%9%Z!<%9$H!$%U%!%$%k$rF1(B
$B;~$KJ#?t?M$,JQ99$9$k$3$H$N$J$$$h$&$K%m%C%/$rMW5a$7$?!%(B

%Later in the 1980s, Dick Grune used RCS as a building block for a set
%of shell scripts he initially called cmt, but then renamed to CVS
%(Concurrent Versions System).  The big innovation of CVS was that it
%let developers work simultaneously and somewhat independently in their
%own personal workspaces.  The personal workspaces prevented developers
%from stepping on each other's toes all the time, as was common with
%SCCS and RCS.  Each developer had a copy of every project file, and
%could modify their copies independently.  They had to merge their
%edits prior to committing changes to the central repository.

1980$BG/Be8eH>$K(BDick Grune$B$O(BRCS$B$r8F$S=P$9%7%'%k%9%/%j%W%H$K$h$k%P!<%8%g%s4I(B
$BM}%7%9%F%`$r:n$C$?!%=i4|$K(Bcmt$B$H8F$P$l$?$3$N%7%9%F%`$O!$8e$K(BCVS
(Concurrent Versions System)$B$H2~L>$5$l$?!%(B CVS$B$NBg$-$J3W?7$O!$3+H/<TC#$K(B
$BF1;~$K8DJL$N%o!<%/%9%Z!<%9$G:n6H$9$k$3$H$r5v$7$?$3$H$G$"$k!%%o!<%/%9%Z!<(B
$B%9$r8DJL$K$7$?$3$H$G!$3+H/<T$O(BSCCS$B$d(BRCS$B$GNI$/$"$C$?$h$&$K!$B>$N3+H/<T$N:n(B
$B6H$rK8$2$k$3$H$,$J$/$J$C$?!%$3$N%b%G%k$G$O!$Cf1{$N%j%]%8%H%j$KJQ99$r%3%_%C(B
$B%H$9$kA0$K!$JQ997k2L$r%^!<%8$9$kI,MW$,$"$C$?!%(B

%Brian Berliner took Grune's original scripts and rewrote them in~C,
%releasing in 1989 the code that has since developed into the modern
%version of CVS.  CVS subsequently acquired the ability to operate over
%a network connection, giving it a client/server architecture.  CVS's
%architecture is centralised; only the server has a copy of the history
%of the project.  Client workspaces just contain copies of recent
%versions of the project's files, and a little metadata to tell them
%where the server is.  CVS has been enormously successful; it is
%probably the world's most widely used revision control system.

Brian Berliner$B$O(BGrune$B$N%*%j%8%J%k%9%/%j%W%H$r<u$17Q$$$G!$$=$l$r(BC$B$G=q$-D>(B
$B$7!$8=:_$N(BCVS$B$X$H7R$,$k%3!<%I$r(B1989$BG/$K%j%j!<%9$7$?!%$=$N8e!$(BCVS$B$O%M%C%H(B
$B%o!<%/$r7PM3$7$?F0:n$d!$%/%i%$%"%s%H%5!<%P%"!<%-%F%/%A%c$rHw$($F$$$C(B
$B$?!%(BCVS$B$N%"!<%-%F%/%A%c$OCf1{=8Cf7?$G!$%5!<%P$N$_$,%W%m%8%'%/%H$NMzNr$rJ](B
$BB8$9$k!%%/%i%$%"%s%H$N%o!<%/%9%Z!<%9$O%W%m%8%'%/%H$N:G?7%P!<%8%g%s$N%U%!(B
$B%$%k$N%3%T!<$G$"$j!$%5!<%P$N=j:_$r<($96O$+$J%a%?%G!<%?$,IU2C$5$l$F$$$?!%(B
CVS$B$OBg@.8y$r<}$a!$$*$=$i$/@$3&$G:G$b9-$/MQ$$$i$l$?%j%S%8%g%s%3%s%H%m!<%k(B
$B%7%9%F%`$H$J$C$?!%(B

%In the early 1990s, Sun Microsystems developed an early distributed
%revision control system, called TeamWare.  A TeamWare workspace
%contains a complete copy of the project's history.  TeamWare has no
%notion of a central repository.  (CVS relied upon RCS for its history
%storage; TeamWare used SCCS.)

1990$BG/Be=iF,!$(BSun Microsystems$B$O(BTeamWare$B$H8F$P$l$k=i4|$NJ,;6%j%S%8%g%s%3(B
$B%s%H%m!<%k%7%9%F%`$r3+H/$7$?!%(BTeamWare$B%o!<%/%9%Z!<%9$O%W%m%8%'%/%H$NMzNr(B
$B$N40A4$J%3%T!<$r;}$C$F$$$?!%(BTeamWare$B$K$OCf1{%j%]%8%H%j$H$$$&35G0$O$J$+$C(B
$B$?!%!J(BCVS$B$,MzNr$N5-O?$K(BRCS$B$r;H$C$F$$$?$h$&$K!$(BTeamWare$B$O(BSCCS$B$rMQ$$$F$$(B
$B$?!%!K(B

%As the 1990s progressed, awareness grew of a number of problems with
%CVS.  It records simultaneous changes to multiple files individually,
%instead of grouping them together as a single logically atomic
%operation.  It does not manage its file hierarchy well; it is easy to
%make a mess of a repository by renaming files and directories.  Worse,
%its source code is difficult to read and maintain, which made the
%``pain level'' of fixing these architectural problems prohibitive.

1990$BG/BeCf:"$K$J$k$H!$(BCVS$B$NLdBj$,9-$/CN$i$l$k$h$&$K$J$C$F$-$?!%(B CVS$B$O0lEY(B
$B$KJ#?t$N%U%!%$%k$KBP$7$F9T$o$l$kJQ99$rO@M}E*$K%"%H%_%C%/$JA`:n(B
\footnote{$BLuCm!'$"$?$+$b86;R$N$h$&$K!$J#?t$NMWAG$KJ,2r$G$-$J$$A`:n$r8@$&(B}$B$H(B
$B$7$F%0%k!<%W2=$9$k$N$G$O$J$/!$%U%!%$%kKh$K8DJL$K5-O?$7$F$$$?!%(BCVS$B$N%U%!%$(B
$B%k%R%(%i%k%-!<$N4IM}$OIT==J,$G!$%U%!%$%k$d%G%#%l%/%H%j$r%j%M!<%`$9$k$H4J(B
$BC1$K%j%]%8%H%j$,:.Mp$7$?!%$5$i$K0-$$$3$H$K!$(BCVS$B$N%=!<%9%3!<%I$OFI$_$K$/(B
$B$/!$%a%s%F%J%s%9$bFq$7$+$C$?$?$a!$%"!<%-%F%/%A%c$NLdBj$r2r7h$9$k$N$OIT2D(B
$BG=$J%l%Y%k$H8@$($?!%(B

%In 2001, Jim Blandy and Karl Fogel, two developers who had worked on
%CVS, started a project to replace it with a tool that would have a
%better architecture and cleaner code.  The result, Subversion, does
%not stray from CVS's centralised client/server model, but it adds
%multi-file atomic commits, better namespace management, and a number
%of other features that make it a generally better tool than CVS.
%Since its initial release, it has rapidly grown in popularity.

2001$BG/!$(BCVS$B$r3+H/$7$F$$$?(BJim Blandy$B$H(BKarl Fogel$B$N(B2$B?M$N3+H/<T$,(BCVS$B$rCV$-49(B
$B$($k!$$h$jM%$l$?%"!<%-%F%/%A%c$H4qNo$J%3!<%I$r;}$D%D!<%k$N%W%m%8%'%/%H$r(B
$B;O$a$?!%$=$N@.2LJ*$G$"$k(BSubversion$B$O(BCVS$B$N=8Cf7?%/%i%$%"%s%H%5!<%P%b%G%k$r(B
$B2~$a$k$3$H$O$7$J$+$C$?$,!$J#?t%U%!%$%k$N%"%H%_%C%/$J%3%_%C%H$rDI2C$7!$L>(B
$BA06u4V$N4IM}$b2~NI$7$F$$$?!%$^$?(BCVS$B$h$j$bM%$l$??tB?$/$N5!G=$bDI2C$5$l$?!%(B
Subversion$B$O:G=i$N%j%j!<%9$+$i5^B.$K?M5$$r3MF@$7$F$$$C$?!%(B

%More or less simultaneously, Graydon Hoare began working on an
%ambitious distributed revision control system that he named Monotone.
%While Monotone addresses many of CVS's design flaws and has a
%peer-to-peer architecture, it goes beyond earlier (and subsequent)
%revision control tools in a number of innovative ways.  It uses
%cryptographic hashes as identifiers, and has an integral notion of
%``trust'' for code from different sources.

$B$[$\;~$rF1$8$/$7$F!$(BGraydon Hoare$B$O(BMonotone$B$H8F$P$l$kLn?4E*$JJ,;6%j%S%8%g(B
$B%s%3%s%H%m!<%k%7%9%F%`$N3+H/$r;O$a$?!%(BMonotone$B$O(BCVS$B$N?tB?$/$N@_7W>e$N`laS(B
$B$r=$@5$7!$%T%"%D!<%T%"%"!<%-%F%/%A%c$r;}$C$F$$$k!%(B Monotone$B$O=i4|$N!J$"$k(B
$B$$$O8eB3$N!K%j%S%8%g%s%3%s%H%m!<%k%D!<%k$h$j$b@h?JE*$J5!G=$r;}$C$F$$(B
$B$k!%(BMonotone$B$O0E9f2=$5$l$?%O%C%7%e$r<1JL;R$H$7$F;HMQ$7!$MM!9$J=P=h$N%3!<(B
$B%I$KBP$7$F(B``$B?.Mj@-(B''$B$N35G0$r;}$C$F$$$?!%(B

%Mercurial began life in 2005.  While a few aspects of its design are
%influenced by Monotone, Mercurial focuses on ease of use, high
%performance, and scalability to very large projects.

Mercurial$B$O(B2005$BG/$KCB@8$7$?!%%G%6%$%s$N$$$/$D$+$NLL$O(BMonotone$B$K1F6A$r<u$1(B
$B$F$$$k$,!$(BMercurial$B$O;H$$$d$9$5!$9b@-G=!$Bg5,LO%W%m%8%'%/%H$X$N%9%1!<%i%S(B
$B%j%F%#$K%U%)!<%+%9$7$F$$$k!%(B

%\section{Trends in revision control}
\section{$B%j%S%8%g%s%3%s%H%m!<%k$N%H%l%s%I(B}

%There has been an unmistakable trend in the development and use of
%revision control tools over the past four decades, as people have
%become familiar with the capabilities of their tools and constrained
%by their limitations.

$B%j%S%8%g%s%3%s%H%m!<%k%D!<%k$N3+H/$H;HMQ$K$*$$$F!$2a5n(B20$BG/4V%D!<%k$K?F$7(B
$B$_!$%D!<%k$N@)8B$rCN$k$K=>$C$F!$J6$l$b$J$$%H%l%s%I$,B8:_$7$F$$$k!%(B

%The first generation began by managing single files on individual
%computers.  Although these tools represented a huge advance over
%ad-hoc manual revision control, their locking model and reliance on a
%single computer limited them to small, tightly-knit teams.

$BBh0l@$Be$N%D!<%k$OC10l$N%U%!%$%k$r8DJL$N%3%s%T%e!<%?$N>e$G4IM}$7$?!%%"%I(B
$B%[%C%/$J<jF0$K$h$k%j%S%8%g%s%3%s%H%m!<%k$HHf$Y$FBgI}$J?JJb$,$"$C$?$,!$%m%C(B
$B%/%b%G%k$HC10l%3%s%T%e!<%?$X$N0MB8$N$?$a!$MxMQ$O>.5,LO$G6[L)$J%A!<%`$K8B(B
$B$i$l$?!%(B

%The second generation loosened these constraints by moving to
%network-centered architectures, and managing entire projects at a
%time.  As projects grew larger, they ran into new problems.  With
%clients needing to talk to servers very frequently, server scaling
%became an issue for large projects.  An unreliable network connection
%could prevent remote users from being able to talk to the server at
%all.  As open source projects started making read-only access
%available anonymously to anyone, people without commit privileges
%found that they could not use the tools to interact with a project in
%a natural way, as they could not record their changes.

$BBhFs@$Be$N%D!<%k$O!$%M%C%H%o!<%/Cf?4$N%"!<%-%F%/%A%c$K0\9T$9$k$3$H$G!$$=(B
$B$l$^$G$N@)8B$r4KOB$7!$%W%m%8%'%/%HA4BN$rF1;~$K4IM}$7$?!%%W%m%8%'%/%H$,Bg(B
$B$-$/@.D9$9$k$H!$?7$?$JLdBj$KD>LL$7$?!%%/%i%$%"%s%H$H%5!<%P$,IQHK$KDL?.$9(B
$B$k$?$a!$Bg5,LO%W%m%8%'%/%H$G$O%5!<%P$N5,LO$,LdBj$K$J$C$?!%?.Mj@-$N$J$$%M%C(B
$B%H%o!<%/@\B3$O%j%b!<%H%f!<%6$,%5!<%P$HDL?.$9$k$N$rK8$2$?!%%*!<%W%s%=!<%9(B
$B%W%m%8%'%/%H$,%3%_%C%H8"$N$J$$%f!<%6$K$bF?L>$NFI$_=P$7@lMQ%"%/%;%9$rDs6!(B
$B$9$k$h$&$K$J$k$H!$%f!<%6$i$O$3$l$i$N%D!<%k$,9T$C$?JQ99$r5-O?$G$-$:!$%W%m(B
$B%8%'%/%H$H$N$d$j$H$j$,ITJX$G$"$k$3$H$KITK~$rJg$i$;$F$$$C$?!%(B

%The current generation of revision control tools is peer-to-peer in
%nature.  All of these systems have dropped the dependency on a single
%central server, and allow people to distribute their revision control
%data to where it's actually needed.  Collaboration over the Internet
%has moved from constrained by technology to a matter of choice and
%consensus.  Modern tools can operate offline indefinitely and
%autonomously, with a network connection only needed when syncing
%changes with another repository.

$B8=9T@$Be$N%j%S%8%g%s%3%s%H%m!<%k%D!<%k$O!$%T%"%D!<%T%"$G$"$k!%$3$l$i$N%7(B
$B%9%F%`$NA4$F$,C10l$NCf1{%5!<%P$X0MB8$7$J$/$J$C$F$*$j!$%j%S%8%g%s%3%s%H%m!<(B
$B%k%G!<%?$rI,MW$J$H$3$m$XJ,;6$5$;$k$3$H$,$G$-$k$h$&$K$J$C$F$$$k!%%$%s%?!<(B
$B%M%C%H$rDL$8$?6&F1:n6H$O5;=QE*@)Ls$+$iN%$l$F!$A*Br$H9g0U$K$h$C$F9T$o$l$k(B
$B$h$&$K$J$C$?!%8=Be$N%D!<%k$O%*%U%i%$%s$N$^$^$G$b!$<+N'E*$K$bF0:n$9$k$h$&(B
$B$K$J$C$F$$$k!%%M%C%H%o!<%/@\B3$OJQ99$rJL$N%j%]%8%H%j$HF14|$5$;$k;~$K$N$_(B
$BI,MW$G$"$k!%(B

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

$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.

$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.

$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.

$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!$%M%C%H%o!<%/$K@\B3$7$J$1$l$P!$Bg$-$J@)8B$N$"$k$$(B
$B$/$D$+$N%3%^%s%I0J30$O;HMQ$G$-$J$$!%J,;6%D!<%k$G$O:n6HCf$K%M%C%H%o!<%/@\(B
$BB3$,CG$?$l$?$H$7$F$b$=$l$K5$$E$/$3$H$9$i$J$$$@$m$&!%B>$N%3%s%T%e!<%?$N%j(B
$B%]%8%H%j$H$NDL?.$r9T$&F0:n$N$_$,1F6A$r<u$1$k!%$3$N$h$&$JF0:n$O%m!<%+%k$G(B
$B$NF0:n$h$jAjBPE*$K>/$J$$$O$:$@!%$3$l$,=EBg$JLdBj$H$J$k$N$O!$9-HO0O$K$o$?(B
$B$k%A!<%`$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.

$B%*!<%W%s%=!<%9%W%m%8%'%/%H$,9%$-$K$J$j!$:n6H$r;O$a$h$&$H$9$k$H$-!$%W%m%8%'(B
$B%/%H$,J,;6%j%S%8%g%s%3%s%H%m!<%k%D!<%k$r;H$C$F$$$l$P!$$?$@$A$K%W%m%8%'%/(B
$B%H$N%3%"%a%s%P!<$NCg4V$H$J$k!%H`$i$,%j%]%8%H%j$r8x3+$7$F$$$l$P!$D>$A$K%W(B
$B%m%8%'%/%HMzNr$r%3%T!<$7!$JQ99$r9T$$!$FbIt$N%a%s%P!<$,;H$C$F$$$k$N$HA4$/(B
$BF1$8%D!<%k$rMQ$$$F:n6H7k2L$r5-O?$9$k$3$H$,$G$-$k!%BP>NE*$K%a%s%P!<$,Cf1{(B
$B=8Cf7?$N%D!<%k$r;H$C$F$$$k>l9g!$C/$+$,$"$J$?$KJQ99$rCf1{$N%5!<%P$K%3%_%C(B
$B%H$9$k5v2D$rM?$($J$$8B$j!$%D!<%k$r%j!<%I%*%s%j!<%b!<%I$G;HMQ$9$k$3$H$K$J(B
$B$k!%$=$l$^$G$OJQ99$r5-O?$9$k$3$H$O$G$-$:!$$"$J$?$N%m!<%+%k$JJQ99$O%j%]%8(B
$B%H%j$N%/%i%$%"%s%H%3%T!<$r99?7$9$k$?$S$KGK2u$5$l$k%j%9%/$rH<$&!%(B

%\subsubsection{The forking non-problem}
\subsubsection{$B%U%)!<%/$7$F$bLdBj$J$7(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.

$B%*!<%W%s%=!<%9%W%m%8%'%/%H$GJ,;6%j%S%8%g%s%3%s%H%m!<%k%D!<%k$rMQ$$$k$3$H(B
$B$O!$%W%m%8%'%/%H$N3+H/$r%U%)!<%/$5$;$k%j%9%/$,$"$k$H8@$o$l$F$$$k!%0U8+$N(B
$BAj0c$d!$3+H/<T$N%0%k!<%W4V$G$NBVEY$N0c$$$+$i!$H`$i$,$=$l0J>e6&$K:n6H$rB3(B
$B$1$k$3$H$,$G$-$J$$$H7hCG$9$k$3$H$G%U%)!<%/$O5/$3$k!%APJ}$N?X1D$O%W%m%8%'(B
$B%/%H$N%=!<%9%3!<%I$N$[$\40A4$J%3%T!<$+$i$=$l$>$l$NJ}8~$KJL$l$F$$$/!%(B

%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.

$B;~$K$O%U%)!<%/$7$??X1D$,!$8_$$$N%3!<%I$N:90[$r2r>C$9$k$3$H$b$"$k!%Cf1{=8(B
$BCf%j%S%8%g%s%3%s%H%m!<%k%7%9%F%`$G$O!$:90[$r(B\emph{$B5;=QE*$K(B}$B2r7h$9$k2aDx$K(B
$B:$Fq$rH<$$!$B?$/$N>l9g!$<jF0$G2r>C$9$kI,MW$,$"$k!%$I$N%j%S%8%g%sMzNr$r;D(B
$B$9$N$+7h$a!$$[$+$N%A!<%`$K$h$kJQ99$r%D%j!<$X$J$s$i$+$NJ}K!$G7Q$.LZ$9$kI,(B
$BMW$,$"$k!%$3$NA`:n$G$O!$DL>o!$0lJ}$N%j%S%8%g%sMzNr$N0lIt$^$?$OA4$F$r<:$&(B
$B$3$H$K$J$k!%(B

%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.

%$BJ,;6%D!<%k$O!$%U%)!<%/$rC1$K%W%m%8%'%/%H$r?J$a$k$?$a$N0l$D$NJ}K!$H$7$F07(B
%$B$&!%$9$Y$F$NJQ99$O@x:_E*$K%U%)!<%/%]%$%s%H$K$J$j$&$k!%$3$N%"%W%m!<%A$NM%(B
%$B0LE@$O!$J,;6%j%S%8%g%s%3%s%H%m!<%k%D!<%k$O%U%)!<%/4V$N(B\emph{$B%^!<%8(B}$B$K6K$a(B
%$B$FM%$l$F$$$k$3$H$@!%%U%)!<%/$O@dBPE*$K4pACE*$J$3$H$G$"$k!'$3$l$O>o$K5/$3(B
%$B$k!%(B

$BJ,;6%D!<%k$O!$%U%)!<%/$r%W%m%8%'%/%H$r?J$a$k$?$a$N0l$D$NJ}K!$H$7$F07$&$K(B
$B$9$.$J$$!%9T$C$?JQ99$9$Y$F$O@x:_E*$K%U%)!<%/%]%$%s%H$K$J$j$&$k!%J,;6%j%S(B
$B%8%g%s%3%s%H%m!<%k%D!<%k$G$O!$%U%)!<%/$OF|>oE*$K5/$-!$$3$l$r<h$j07$&$3$H(B
$B$OF0:n$N:,K\$G$"$k!%$=$N$?$a%U%)!<%/4V$N(B\emph{$B%^!<%8(B}$B$K$O6K$a$FM%$l$F$*(B
$B$j!$$3$l$,J,;6%D!<%k$K$h$k%"%W%m!<%A$NBg$-$JMxE@$H$J$C$F$$$k!%(B

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

$B3F?M$,9T$&A4$F$NItJ,:n6H$,%U%)!<%/$H%^!<%8$K0LCVIU$1$i$l$k$J$i$P!$%*!<%W(B
$B%s%=!<%93&$O(B``$B%U%)!<%/(B''$B$r(B\emph{$B=c?h$K(B}$B<R2qE*$J;v>]$H$7$F07$&$@$m$&!%$$$:(B
$B$l$K$;$hJ,;6%D!<%k$O%U%)!<%/$N38A3@-$r(B\emph{$B2<$2$k(B}$B!'(B

%\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}
\begin{itemize}
 \item $BCf1{=8CfE*$J%D!<%k$,2]$9!$%3%_%C%H8"$r;}$C$?FbIt$N?M4V$H;}$?$J$$30(B
       $BIt$N?M4V$N<R2qE*$J6hJL$r<h$j5n$k(B
 \item $B%j%S%8%g%s%3%s%H%m!<%k%=%U%H%&%'%"$N4QE@$+$i$OF1$8%^!<%8$G$"$k$?(B
       $B$a!$3+H/%3%_%e%K%F%#$N%U%)!<%/8e$K@8$8$?:90[$r2r>C$9$k$N$,MF0W$K$J(B
       $B$k!%(B
\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.

$B%W%m%8%'%/%H$r873J$K%3%s%H%m!<%k$7$?$$$?$a$KJ,;6%D!<%k$K93$&?M!9$b$$$k!%(B
$BH`$i$OCf1{=8Cf%D!<%k$,$3$N$h$&$J%3%s%H%m!<%k$rM?$($k$H9M$($F$$$k!%$7$+$7(B
$B$=$&;W$C$F$$$F$b!$(BCVS$B$d(BSubversion$B%j%]%8%H%j$r8x3+$9$l$P!$(B $B!J;~4V$O$+$+$C(B
$B$F$b!K%W%m%8%'%/%H$NMzNrA4BN$r<hF@$7$F!$%3%s%H%m!<%k$N<j$N5Z$P$J$$$I$3$+(B
$B$G$=$l$r:F8=$9$kJ}K!$O$$$/$i$G$b$"$k!%7k6I!$MzNr$r%_%i!<$7!$%U%)!<%/$9$k(B
$B$h$&$JN.F0E*$J6(NO$rGS=|$9$k$h$&$J%3%s%H%m!<%k$OHs8=<BE*$G$"$k!%(B

%\subsection{Advantages for commercial projects}
\subsection{$B>&MQ%W%m%8%'%/%H$G$NMxE@(B}

%Many commercial projects are undertaken by teams that are scattered
%across the globe.  Contributors who are far from a central server will
%see slower command execution and perhaps less reliability.  Commercial
%revision control systems attempt to ameliorate these problems with
%remote-site replication add-ons that are typically expensive to buy
%and cantankerous to administer.  A distributed system doesn't suffer
%from these problems in the first place.  Better yet, you can easily
%set up multiple authoritative servers, say one per site, so that
%there's no redundant communication between repositories over expensive
%long-haul network links.

$B>&MQ%W%m%8%'%/%H$NB?$/$OCOM}E*$K9-$,$C$?%A!<%`$K$h$C$F3+H/$5$l$F$$$k!%Cf(B
$B1{%5!<%P$O!$1s$/N%$l$?6(NO<T$+$i$O%3%^%s%I<B9T$,CY$+$C$?$j!$?.Mj@-$,Dc$+$C(B
$B$?$j$9$k$h$&$K8+$($k!%>&MQ%j%S%8%g%s%3%s%H%m!<%k%7%9%F%`$O$3$NLdBj$N2r7h(B
$B$K%j%b!<%H%5%$%H$NJ#@=$r:n@.$9$k%"%I%*%s$rDs6!$7$F$$$k!%$3$l$i$NB?$/$O9b(B
$B2A$@$C$?$j!$4IM}$,J#;($@$H$$$&LdBj$r;}$C$F$$$k!%J,;6%7%9%F%`$K$O$=$b$=$b(B
$B$3$l$i$NLdBj$,$J$$!%$5$i$K9%$^$7$$$3$H$K!$J#?t$N%5%$%HKh$K@5<0$J%5!<%P$r(B
$B4JC1$K@_Dj$9$k$3$H$,$G$-!$9b2A$JD95wN%$N%M%C%H%o!<%/%j%s%/>e$K>iD9$JDL?.(B
$B$r9T$&$3$H$,$J$$!%(B

%Centralised revision control systems tend to have relatively low
%scalability.  It's not unusual for an expensive centralised system to
%fall over under the combined load of just a few dozen concurrent
%users.  Once again, the typical response tends to be an expensive and
%clunky replication facility.  Since the load on a central server---if
%you have one at all---is many times lower with a distributed
%tool (because all of the data is replicated everywhere), a single
%cheap server can handle the needs of a much larger team, and
%replication to balance load becomes a simple matter of scripting.

$BCf1{=8Cf7?$N%j%S%8%g%s%3%s%H%m!<%k%7%9%F%`$N%9%1!<%i%S%j%F%#$OAjBPE*$K>.(B
$B$5$/!$?t==?M$N%f!<%6$NF1;~%"%/%;%9$K$h$kIi2Y$GCf1{$N9b2A$J%7%9%F%`$,Dd;_(B
$B$9$k$3$H$bDA$7$/$J$$!%$7$+$7!$$3$l$K9b2A$GJ#;($JJ#@=5!G=$rDI2C$9$k$3$H$,(B
$B$h$/9T$o$F$7$^$&!%$?$@0l$D$NCf1{%5!<%P$N$_$r;}$D>l9g$G$b!$J,;6%D!<%k$rMQ(B
$B$$$k$3$H$G!J%G!<%?$O$9$Y$F$"$i$f$k$H$3$m$KJ#@=$5$l$k$?$a!KCf1{%5!<%P$NIi(B
$B2Y$O?tJ,$N0l$KM^$($i$l$k!%$3$N$?$aC10l$N0B2A$J%5!<%P$GBg$-$J%A!<%`$N<{MW(B
$B$rK~$?$9$3$H$,$G$-!$Ii2YJ,;6$N$?$a$N%G!<%?$NJ#@=$b%9%/%j%W%H$@$1$G<B8=$G(B
$B$-$k!%(B

%If you have an employee in the field, troubleshooting a problem at a
%customer's site, they'll benefit from distributed revision control.
%The tool will let them generate custom builds, try different fixes in
%isolation from each other, and search efficiently through history for
%the sources of bugs and regressions in the customer's environment, all
%without needing to connect to your company's network.

$B8\5R$NB&$G$3$NNN0h$NLdBj2r7h$r9T$&=>6H0w$,$$$l$P!$J,;6%j%S%8%g%s%3%s%H%m!<(B
$B%k$NMx1W$rF@$k$3$H$,$G$-$k!%%D!<%k$r;H$&$3$H$G!$%+%9%?%`%S%k%I!$8_$$$KFH(B
$BN)$7$?=$@5$N%F%9%H!$%W%m%8%'%/%H$NMzNr$+$i%P%0$d%j%0%l%C%7%g%s$N860x$NC5(B
$B:w$J$I$r8\5R$N4D6-$G%M%C%H%o!<%/$K@\B3$9$kI,MW$J$/<B8=$G$-$k!%(B

%\section{Why choose Mercurial?}
\section{Mercurial$B$rA*$VM}M3(B}

%Mercurial has a unique set of properties that make it a particularly
%good choice as a revision control system.
Mercurial$B$O!$%j%S%8%g%s%3%s%H%m!<%k%7%9%F%`$H$7$FA*Br$9$k$N$K$U$5$o$7$$(B
$B%f%K!<%/$J@-<A$r;}$C$F$$$k!%(B
\begin{itemize}
%\item It is easy to learn and use.
%\item It is lightweight.
%\item It scales excellently.
%\item It is easy to customise.
\item $B3X=,$HMxMQ$,4JC1(B
\item $B7ZNL$G$"$k(B
\item $B6K$a$FNI9%$K%9%1!<%k$9$k(B
\item $B%+%9%?%^%$%:$,MF0W$G$"$k(B
\end{itemize}

%If you are at all familiar with revision control systems, you should
%be able to get up and running with Mercurial in less than five
%minutes.  Even if not, it will take no more than a few minutes
%longer.  Mercurial's command and feature sets are generally uniform
%and consistent, so you can keep track of a few general rules instead
%of a host of exceptions.

$BFI<T$,%j%S%8%g%s%3%s%H%m!<%k$K47$l$F$$$k$N$G$"$l$P!$(B Mercurial$B$r(B5$BJ,0JFb$K(B
$B;H$$;O$a$k$3$H$,$G$-$k$@$m$&!%(B $B2>$K(B5$BJ,$,L5M}$G$b!$$"$H?tJ,$b$"$l$P==J,$K(B
$B0c$$$J$$!%(B Mercurial$B$N%3%^%s%I$H5!G=%;%C%H$OA4BN$K6Q0l$G0l4S@-$,$"$k$N(B
$B$G!$B??t$NNc30$r3P$($k$N$G$O$J$/!$6&DL$9$k%k!<%k$5$(3P$($F$*$1$P$h$$!%(B

%On a small project, you can start working with Mercurial in moments.
%Creating new changes and branches; transferring changes around
%(whether locally or over a network); and history and status operations
%are all fast.  Mercurial attempts to stay nimble and largely out of
%your way by combining low cognitive overhead with blazingly fast
%operations.

$B>.$5$J%W%m%8%'%/%H$G$O!$$9$0$K(BMercurial$B$r;H$$;O$a$k$3$H$,$G$-$k!%?7$7$$JQ(B
$B99$H%V%i%s%A$r:n$j!$!J%m!<%+%k$d%M%C%H%o!<%/1[$7$K!KJQ99$rE>Aw$7!$MzNr$H(B
$B>uBV$K4X$9$kF0:n$O$9$Y$F9bB.$G$"$k!%(B Mercurial$B$N8D!9$NF0:n$O6K$a$F9bB.$G(B
$B$"$j!$A4BN$H$7$F$bAGAa$/!$%*!<%P%X%C%I$,$[$H$s$ICN3P$G$-$J$$$h$&$JF0:n$r(B
$B$9$k$h$&$K$J$C$F$$$k!%(B

%The usefulness of Mercurial is not limited to small projects: it is
%used by projects with hundreds to thousands of contributors, each
%containing tens of thousands of files and hundreds of megabytes of
%source code.

Mercurial$B$NM-MQ@-$O!$>.$5$J%W%m%8%'%/%H$K8B$i$J$$!%(BMercurial$B$O?tI4?M$+$i(B
$B?t@i?M$N9W8%<T$rMJ$7!$?tK|$N%U%!%$%k$+$i$J$k?tI4%a%,%P%$%H$K$b5Z$V%=!<%9(B
$B%3!<%I$+$i$J$k%W%m%8%'%/%H$G$bM-8z$G$"$k!%(B

%If the core functionality of Mercurial is not enough for you, it's
%easy to build on.  Mercurial is well suited to scripting tasks, and
%its clean internals and implementation in Python make it easy to add
%features in the form of extensions.  There are a number of popular and
%useful extensions already available, ranging from helping to identify
%bugs to improving performance.

Mercurial$B$N3K$K$J$k5!G=$,==J,$G$J$+$C$?>l9g!$3HD%$9$k$3$H$O$?$d$9$$!%(B
Mercurial$B$O%9%/%j%W%H$H$h$/Fk@w$`!%$^$?@0$C$?FbIt9=B$$H(BPython$B$K$h$k<BAu$N(B
$B$?$a!$3HD%$N7A$G?7$7$$5!G=$rDI2C$9$k$N$,MF0W$G$"$k!%%P%0$N<1JL$r=u$1$k$b(B
$B$N$+$i!$@-G=$r2~A1$9$k$b$N$^$G!$?M5$$N9b$$M-MQ$J3HD%$,$9$G$K?tB?$/B8:_$7(B
$B$F$$$k!%(B

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

$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}

%Subversion is a popular revision control tool, developed to replace
%CVS.  It has a centralised client/server architecture.

Subversion$B$O!$(BCVS$B$rCV$-49$($k$Y$/3+H/$5$l$?!$?M5$$N9b$$%j%S%8%g%s%3%s%H%m!<(B
$B%k%D!<%k$G$"$k!%$3$l$bCf1{=8Cf7?$N%/%i%$%"%s%H%5!<%P%"!<%-%F%/%A%c$r;}$D!%(B

%Subversion and Mercurial have similarly named commands for performing
%the same operations, so if you're familiar with one, it is easy to
%learn to use the other.  Both tools are portable to all popular
%operating systems.

Subversion$B$H(BMercurial$B$G$O!$F1$8F0:n$N$?$a$N%3%^%s%I$KF1MM$NL>A0$,IU$1$i$l(B
$B$F$$$k$?$a!$$I$A$i$+$K47$l$F$$$l$P$b$&0lJ}$r3X$V$N$O$?$d$9$$!%$I$A$i$N%D!<(B
$B%k$b$9$Y$F$N?M5$$N9b$$%*%Z%l!<%F%#%s%0%7%9%F%`$K0\?"$5$l$F$$$k!%(B

%Subversion lacks a history-aware merge capability, forcing its users
%to manually track exactly which revisions have been merged between
%branches.  If users fail to do this, or make mistakes, they face the
%prospect of manually resolving merges with unnecessary conflicts.
%Subversion also fails to merge changes when files or directories are
%renamed.  Subversion's poor merge support is its single biggest
%weakness.

%Subversion$B$OMzNr$r9MN8$7$?%^!<%8$N5!G=$r7g$$$F$*$j!$@53N$K$I$N%j%S%8%g%s(B
%$B$,%V%i%s%A4V$G%^!<%8$5$l$?$N$+%f!<%6<+?H$,%H%i%C%/$9$kI,MW$,$"$k!#%f!<%6(B
%$B$,DI$$@Z$l$J$+$C$?>l9g$d4V0c$$$rHH$7$?>l9g!$I,MW$N$J$$%3%s%U%j%/%H$r<jF0(B
%$B$G2r7h$9$k$3$H$K$J$k!%(BSubversion$B$O%U%!%$%k$d%G%#%l%/%H%j$,%j%M!<%`$5$l$F(B
%$B$$$?>l9g$b%^!<%8$K<:GT$9$k!%%^!<%8%5%]!<%H$N<e$5$O(BSubversion$B$N:GBg$N<eE@(B
%$B$N0l$D$G$"$k!%(B

%Mercurial has a substantial performance advantage over Subversion on
%every revision control operation I have benchmarked.  I have measured
%its advantage as ranging from a factor of two to a factor of six when
%compared with Subversion~1.4.3's \emph{ra\_local} file store, which is
%the fastest access method available.  In more realistic deployments
%involving a network-based store, Subversion will be at a substantially
%larger disadvantage.  Because many Subversion commands must talk to
%the server and Subversion does not have useful replication facilities,
%server capacity and network bandwidth become bottlenecks for modestly
%large projects.

Mercurial$B$OI.<T$,%Y%s%A%^!<%/$r9T$C$?A4$F$N%j%S%8%g%s%3%s%H%m!<%kA`:n$K$*(B
$B$$$F(BSubversion$B$h$j$bL@3N$J@-G=>e$NM%0L@-$r;}$C$F$$$k!%I.<T$O(B2$B$+$i(B6$B$^$G$N(B
$BHO0O$GM%0L@-$r(BSubversion~1.4.3$B$GMxMQ2DG=$JCf$G:G$b9bB.$J(B\emph{ra\_$B%m!<%+(B
$B%k(B}$B%U%!%$%kJ]B8$HHf3S$7$?!%$h$j8=<BE*$JMxMQ$G$O%M%C%H%o!<%/$rMxMQ$7$?%U%!(B
$B%$%k%5!<%S%9$rMQ$$$k$3$H$K$J$j!$(BSubversion$B$G$OL@3N$KBg$-$JITMx$,$"$k!%B?(B
$B$/$N(BSubversion$B%3%^%s%I$O%5!<%P$HDL?.$9$kI,MW$,$"$j!$(BSubversion$B$O<BMQE*$J(B
$BJ#@=5!9=$r;}$?$J$$$?$a!$0lDj0J>e$N5,LO$N%W%m%8%'%/%H$G$O!$%5!<%P%-%c%Q%7(B
$B%F%#$H%M%C%H%o!<%/$N%P%s%II}$,%\%H%k%M%C%/$H$J$k$+$i$G$"$k!%(B

%Additionally, Subversion incurs substantial storage overhead to avoid
%network transactions for a few common operations, such as finding
%modified files (\texttt{status}) and displaying modifications against
%the current revision (\texttt{diff}).  As a result, a Subversion
%working copy is often the same size as, or larger than, a Mercurial
%repository and working directory, even though the Mercurial repository
%contains a complete history of the project.

$B$5$i$K!$(BSubversion$B$O99?7$5$l$?%U%!%$%k$NC5:w(B(\texttt{status})$B$H!$8=:_$N%j(B
$B%S%8%g%s$KBP$9$k:9J,$N$rI=<((B(\texttt{diff})$B$J$I$N$$$/$D$+$NA`:n$G%M%C%H%o!<(B
$B%/%H%i%s%6%/%7%g%s$rHr$1$k$?$a$KL@3N$J%9%H%l!<%8%*!<%P%X%C%I$r$b$?$i$9!%(B
$B7k2L$H$7$F!$(BSubversion$B$N%o!<%-%s%0%3%T!<$O!$%W%m%8%'%/%H$N40A4$JMzNr$r4^(B
$B$`(BMercurial$B$N%j%]%8%H%j5Z$S%o!<%-%s%0%G%#%l%/%H%j$HF1$8$+$h$jBg$-$J%5%$%:(B
$B$H$J$C$F$7$^$&!%(B

%Subversion is widely supported by third party tools.  Mercurial
%currently lags considerably in this area.  This gap is closing,
%however, and indeed some of Mercurial's GUI tools now outshine their
%Subversion equivalents.  Like Mercurial, Subversion has an excellent
%user manual.

Subversion$B$K$OB?$/$N%5!<%I%Q!<%F%#%D!<%k$,$"$k!%(BMercurial$B$O$3$NE@$G$+$J$j(B
$BCY$l$F$$$k!%%.%c%C%W$O=L$^$j$D$D$"$k$,!$(BMercurial$B$N(BGUI$B%D!<%k$N$$$/$D$+(B
$B$O!$BP1~$9$k(BSubversion$BMQ$N$b$N$h$j$b=($G$F$$$k!%(BSubversion$B$K$O(BMercurial$B$H(B
$BF1MM$KM%$l$?%f!<%6%^%K%e%"%k$,$"$k!%(B

%Because Subversion doesn't store revision history on the client, it is
%well suited to managing projects that deal with lots of large, opaque
%binary files.  If you check in fifty revisions to an incompressible
%10MB file, Subversion's client-side space usage stays constant. The
%space used by any distributed SCM will grow rapidly in proportion to
%the number of revisions, because the differences between each revision
%are large.

Subversion$B$O%j%S%8%g%s$NMzNr$r%/%i%$%"%s%HFb$K;}$?$J$$$?$a!$%5%$%:$,Bg$-(B
$B$/FbMF$NL@$i$+$G$J$$B??t$N%P%$%J%j%U%!%$%k$r<h$j07$&$N$K$O8~$$$F$$$k!%(B
$B05=L$N8z$+$J$$(B10MB$B$N%U%!%$%k$KBP$7$F(B50$B%j%S%8%g%s$r%A%'%C%/%$%s$9$k>l(B
$B9g!$(BSubversion$B$N%/%i%$%"%s%HB&$N%9%H%l!<%8$N;HMQNL$O0lDj$G$"$k!%(B
$BJ,;6(BSCM$B$G$O!$%9%H%l!<%8;HMQNL$O3F!9$N%j%S%8%g%s4V$G$N:9J,$,Bg$-$$$?$a!$%j(B
$B%S%8%g%s?t$KHfNc$7$F$9$0$KA}$($F$7$^$&!%(B

%In addition, it's often difficult or, more usually, impossible to
%merge different versions of a binary file.  Subversion's ability to
%let a user lock a file, so that they temporarily have the exclusive
%right to commit changes to it, can be a significant advantage to a
%project where binary files are widely used.

$B2C$($F!$0[$J$k%P!<%8%g%s$N%P%$%J%j%U%!%$%k$r%^!<%8$9$k$N$OIT2DG=$G$"$C$?(B
$B$j!$:$Fq$G$"$C$?$j$9$k!%(B Subversion$B$G$O%U%!%$%k%m%C%/5!G=$K$h$C$F%f!<%6$,(B
$B0l;~E*$K%U%!%$%k$X$NJQ99$r%3%_%C%H$9$kGSB>E*$J8"Mx$rF@$k$3$H$,$G$-$k!%$3(B
$B$l$O%P%$%J%j%U%!%$%k$r9-HF$K;H$&%W%m%8%'%/%H$G$OBg$-$JMxE@$K$J$jF@$k!%(B

%Mercurial can import revision history from a Subversion repository.
%It can also export revision history to a Subversion repository.  This
%makes it easy to ``test the waters'' and use Mercurial and Subversion
%in parallel before deciding to switch.  History conversion is
%incremental, so you can perform an initial conversion, then small
%additional conversions afterwards to bring in new changes.

Mercurial$B$O(BSubversion$B%j%]%8%H%j$+$i%j%S%8%g%sMzNr$r%$%s%]!<%H$9$k$3$H$,$G(B
$B$-$k!%$^$?!$%j%S%8%g%sMzNr$r(BSubversion$B%j%]%8%H%j$K%(%/%9%]!<%H$9$k$3$H$b(B
$B2DG=$@!%$3$N$?$a!$0\9T$r7h$a$kA0$K(BMercurial$B$r;n$7$?$j!$(BMercurial$B$r(B
Subversion$B$HJB9T$7$FMxMQ$9$k$3$H$,MF0W$G$"$k!%(B
$BMzNr$NJQ49$OA2?JE*$K9T$($k$?$a!$:G=i$KJQ49$r9T$C$?8e!$?7$?$JJQ99$r<h$j9~(B
$B$`$?$a$KDI2C$NJQ49$r9T$&$3$H$,$G$-$k!%(B

\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$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$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.

$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.

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

%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}

%CVS is probably the most widely used revision control tool in the
%world.  Due to its age and internal untidiness, it has been only
%lightly maintained for many years.

CVS$B$O$*$=$i$/@$3&Cf$G:G$b9-HO$K;HMQ$5$l$F$$$k%j%S%8%g%s%3%s%H%m!<%k%D!<(B
$B%k$G$"$m$&!%$=$N8E$5$HFbIt$NMp;($5$N$?$a!$D9$i$/7Z$$%a%s%F%J%s%9$N$_$,9T(B
$B$o$l$F$-$?!%(B

%It has a centralised client/server architecture.  It does not group
%related file changes into atomic commits, making it easy for people to
%``break the build'': one person can successfully commit part of a
%change and then be blocked by the need for a merge, causing other
%people to see only a portion of the work they intended to do.  This
%also affects how you work with project history.  If you want to see
%all of the modifications someone made as part of a task, you will need
%to manually inspect the descriptions and timestamps of the changes
%made to each file involved (if you even know what those files were).

CVS$B$O=8Cf7?$N%/%i%$%"%s%H%5!<%P%"!<%-%F%/%A%c$r;}$D!%(BCVS$B$O!$4XO"$7$?%U%!(B
$B%$%kJQ99$r%0%k!<%W2=$7!$%"%H%_%C%/$K%3%_%C%H$9$k$3$H$,$G$-$J$$!%$3$N$?$a(B
$B%f!<%6$,%3%_%C%H$K$h$C$F%S%k%I$rGK2u$9$k$3$H$,5/$3$k!%C/$+$,JQ99$N0lIt$r(B
$B@.8yN"$K%3%_%C%H$7$?$b$N$N!$;D$j$NItJ,$O%^!<%8$,I,MW$J$?$a%V%m%C%/$5$l$F(B
$B$$$k>l9g!$B>$N%f!<%6$OI,MW$JJQ99$N0lIt$7$+8+$k$3$H$,$G$-$J$$!%F1$8$3$H$O(B
$B%W%m%8%'%/%H$NMzNr$KBP$7$F$b5/$3$k!%C/$+$N:n6H$K4X78$9$kJQ99$9$Y$F$r;2>H(B
$B$7$?$$>l9g!$!J$I$N%U%!%$%k$,2?$J$N$+CN$C$F$$$l$P!K4XO"$9$k3F%U%!%$%k$K$D(B
$B$$$F!$JQ99$N@bL@$H%?%$%`%9%?%s%W$r<+NO$GD4$Y$FJQ99$rFCDj$9$kI,MW$,$"$k!%(B

%CVS has a muddled notion of tags and branches that I will not attempt
%to even describe.  It does not support renaming of files or
%directories well, making it easy to corrupt a repository.  It has
%almost no internal consistency checking capabilities, so it is usually
%not even possible to tell whether or how a repository is corrupt.  I
%would not recommend CVS for any project, existing or new.

CVS$B$N%?%0$H%V%i%s%A$O8l$k5$$5$(5/$-$J$$$h$&$J:.Mp$7$?7A<0$r;}$C$F$$$k!%$-(B
$B$A$s$H$7$?%U%!%$%k$d%G%#%l%/%H%j$N%j%M!<%`$r%5%]!<%H$7$J$$$?$a!$%j%]%8%H(B
$B%j$,4JC1$K2u$l$F$7$^$&!%(B cvs$B$OFbIt$G0l4S@-$r%A%'%C%/$9$k5!G=$,$J$/!$%j%](B
$B%8%H%j$NGKB;$rCN$i$;$k$3$H$b$G$-$J$$!%I.<T$O4{B8$^$?$O?75,$rLd$o$:!$$I$N(B
$B$h$&$J%W%m%8%'%/%H$G$"$C$F$b(BCVS$B$N;HMQ$OA&$a$J$$!%(B

%Mercurial can import CVS revision history.  However, there are a few
%caveats that apply; these are true of every other revision control
%tool's CVS importer, too.  Due to CVS's lack of atomic changes and
%unversioned filesystem hierarchy, it is not possible to reconstruct
%CVS history completely accurately; some guesswork is involved, and
%renames will usually not show up.  Because a lot of advanced CVS
%administration has to be done by hand and is hence error-prone, it's
%common for CVS importers to run into multiple problems with corrupted
%repositories (completely bogus revision timestamps and files that have
%remained locked for over a decade are just two of the less interesting
%problems I can recall from personal experience).

Mercurial$B$O(BCVS$B$N%j%S%8%g%sMzNr$r%$%s%]!<%H$9$k$3$H$,$G$-$k!%$7$+$7B>$N%j(B
$B%S%8%g%s%3%s%H%m!<%k%D!<%k$N(BCVS$B%$%s%]!<%?!<F1MM$$$/$D$+$N@)8B$b$"$k!%(B
CVS$B$K$O%"%H%_%C%/%A%'%s%8$,$J$/!$%U%!%$%k%7%9%F%`3,AX$r%P!<%8%g%s4IM}$9(B
$B$kG=NO$b$J$$$?$a!$(BCVS$B$NMzNr$r40A4$+$D@53N$K:F8=$9$k$3$H$O$G$-$J$$!%:F8=(B
$B$K$O$$$/$D$+$N?dB,$,F~$j!$%j%M!<%`$ODL>o:F8=$5$l$J$$!%(B
CVS$B$G$O9bEY$J4IM}$NB?$/$,<jF0$G9T$o$l$k$?$a!$4V0c$$$,5/$3$j$d$9$/!$GKB;$7(B
$B$?%j%]%8%H%j$G(BCVS$B%$%s%]!<%?!<$,F1;~$KJ#?t$NLdBj$K8+Iq$o$l$k$3$H$,$h$/$"(B
$B$k!%!JI.<T$NITL{2w$JBN83$G$O!$(B10$BG/0J>e$K$o$?$C$F%m%C%/$5$l$?$^$^$N40A4$K(B
$BL50UL#$J%j%S%8%g%s%?%$%`%9%?%s%W$d%U%!%$%k$r8+$?$3$H$,$"$k!%!K(B

%Mercurial can import revision history from a CVS repository.

Mercurial$B$O(BCVS$B%j%]%8%H%j$+$i%j%S%8%g%sMzNr$r%$%s%]!<%H$9$k$3$H$,$G$-$k!%(B

%\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$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.

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,MW(B
$B$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.

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.

$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!%(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$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
\item Git
\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.

$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.

\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
%%% TeX-master: "00book"
%%% End: