Mercurial > hgbook
view ja/intro.tex @ 800:1a30d2627512
Propagate 2ff0a43f1152
Update ch03
| author | Yoshiki Yazawa <yaz@honeyplanet.jp> |
|---|---|
| date | Thu, 18 Jun 2009 20:04:44 +0900 |
| parents | fa1c3715254d |
| children | 8a3041e6f3cb |
line wrap: on
line source
%\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$r$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$b(B $BBg$-$J?t;z$r4^$`?7$?$JL>A0$G%;!<%V$r9T$&$J$I$NJ}K!$GA4$F<j$G9T$&$3$H$G$"(B $B$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 $BB>$N?M$H:n6H$7$F$$$k;~!$%j%S%8%g%s%3%s%H%m!<%k%=%U%H%&%'%"$O6&F1(B $B:n6H$r=u$1$k!%Nc$($P!$?M!9$,F1;~$K8_49@-$N$J$$JQ99$r9T$C$?>l9g!$(B $B%=%U%H%&%'%"$O%3%s%U%j%/%H$rFCDj$7!$2D7h$9$k$3$H$r=u$1$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$N<BMQ@-$K4X$9$k80$K$J$k<ALd$O!$$3$l$i$N(B2$B$D$N0[$J$C(B $B$?%9%1!<%k!J(B``$B0l?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!$%3%9%H$KBP$7$F$I$l$@$1Mx1W$,$"$k$N$+$H$$$&$3$H$G$"$k!%M}2r$d;HMQ$,(B $B:$Fq$J%j%S%8%g%s%3%s%H%m!<%k%D!<%k$O9b$$%3%9%H$r2!$7$D$1$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$O<:GT$9$k$3$H$,KX$s(B $B$IL@Gr$J$?$a!$%j%S%8%g%s%3%s%H%m!<%k$r9T$&%3%9%H$rJ'$&$3$H$OFC$KLdBj$H$O(B $B$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$H$7$F%0%k!<(B $B%W2=$9$k$N$G$O$J$/!$%U%!%$%kKh$K8DJL$K5-O?$7$F$$$?!%(BCVS$B$N%U%!%$%k%R%(%i%k(B $B%-!<$N4IM}$OIT==J,$G!$%U%!%$%k$d%G%#%l%/%H%j$r%j%M!<%`$9$k$H4JC1$K%j%]%8(B $B%H%j$,:.Mp$7$?!%$5$i$K0-$$$3$H$K!$(BCVS$B$N%=!<%9%3!<%I$OFI$_$K$/$/!$%a%s%F%J(B $B%s%9$bFq$7$+$C$?$?$a!$%"!<%-%F%/%A%c$NLdBj$r2r7h$9$k$N$OIT2DG=$J%l%Y%k$H(B $B8@$($?!%(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$,%5!<%P$KIQHK$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!$%D!<%k$OH`$i$N9T$C$?JQ99$r5-O?$G$-$J$$$?$a!$%W%m%8%'%/(B $B%H$H$d$j$H$j$r9T$&<+A3$J<jCJ$H$O8@$($J$$$3$H$,$o$+$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!$$$$/$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. $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$^$?$OA4BN$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$,>o$K9T$&:n6H$NCGJR$,%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$9$k$H!$F1$8%^!<%8$G$"(B $B$k$?$a!$<R2qE*$J%U%)!<%/$N8e$K:90[$r2r>C$9$k$N$rMF0W$K$9$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,(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. 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: