changeset 377:4a9d7e24b915

a bit more hook.tex

--- a/ja/hook.tex	Fri Jan 09 18:07:12 2009 +0900
+++ b/ja/hook.tex	Fri Jan 09 22:13:32 2009 +0900
@@ -379,39 +379,64 @@
 $B$J$$$b$N$G$"$k!%%U%C%/$,<B9T$5$l$F$$$k;~4V$,D9$/$J$l$P$J$k$[$I!$%?%$%`%&%#(B
 $B%s%I%&$,3+$/;~4V$bD9$/$J$k!%(B
 
-
 %\subsection{The problem illustrated}
 \subsection{$BLdBj$N>\:Y(B}
 
-In principle, a good use for the \hook{pretxnchangegroup} hook would
-be to automatically build and test incoming changes before they are
-accepted into a central repository.  This could let you guarantee that
-nobody can push changes to this repository that ``break the build''.
-But if a client can pull changes while they're being tested, the
-usefulness of the test is zero; an unsuspecting someone can pull
-untested changes, potentially breaking their build.
+%In principle, a good use for the \hook{pretxnchangegroup} hook would
+%be to automatically build and test incoming changes before they are
+%accepted into a central repository.  This could let you guarantee that
+%nobody can push changes to this repository that ``break the build''.
+%But if a client can pull changes while they're being tested, the
+%usefulness of the test is zero; an unsuspecting someone can pull
+%untested changes, potentially breaking their build.
+
+$B<BMQ$K$*$1$k(B\hook{pretxnchangegroup}$B%U%C%/$NNI$$;HMQK!$H$7$F$O!$E~Ce$7$?(B
+$BJQ99$,Cf1{$N%j%]%8%H%j$K<h$j9~$^$l$kA0$K<+F0$G%S%k%I$H%F%9%H$r9T$&$3$H$,(B
+$B9M$($i$l$k!%$3$l$K$h$j!$%S%k%I$rK8$2$kJQ99$OC/$b%j%]%8%H%j$K(Bpush$B$G$-$J$$(B
+$B$3$H$,3N<B$K$J$k!%%/%i%$%"%s%H$,%F%9%HCf$KJQ99$r(Bpull$B$9$k$3$H$,$G$-$l$P!$(B
+$B$3$N%F%9%H$NM-MQ@-$O%<%m$K$J$C$F$7$^$&!%5?$$$r;}$?$:$KC/$+$,%F%9%H$5$l$F(B
+$B$$$J$$JQ99$r(Bpull$B$G$-$k$N$G$"$l$P!$H`$i$N%S%k%I$O<:GT$9$k2DG=@-$,$"$k!%(B
+
+%The safest technological answer to this challenge is to set up such a
+%``gatekeeper'' repository as \emph{unidirectional}.  Let it take
+%changes pushed in from the outside, but do not allow anyone to pull
+%changes from it (use the \hook{preoutgoing} hook to lock it down).
+%Configure a \hook{changegroup} hook so that if a build or test
+%succeeds, the hook will push the new changes out to another repository
+%that people \emph{can} pull from.
 
-The safest technological answer to this challenge is to set up such a
-``gatekeeper'' repository as \emph{unidirectional}.  Let it take
-changes pushed in from the outside, but do not allow anyone to pull
-changes from it (use the \hook{preoutgoing} hook to lock it down).
-Configure a \hook{changegroup} hook so that if a build or test
-succeeds, the hook will push the new changes out to another repository
-that people \emph{can} pull from.
+$B$3$NLdBj$X$N5;=QE*$K:G$b0BA4$J2sEz$O!$(B``$BLgHV(B''$B%j%]%8%H%j$r(B\emph{$B0lJ}8~(B}$B$K(B
+$B@_Dj$9$k$3$H$G$"$k!%%j%]%8%H%j$r30It$+$i(Bpush$B$5$l$?JQ99$r<u$1<h$k$,!$C/$b(B
+pull$B$G$-$J$$$h$&$K@_Dj$9$k!J(B\hook{preoutgoing}$B%U%C%/$r;H$C$F%j%]%8%H%j$r(B
+$B%m%C%/$9$k!K!%(B\hook{changegroup}$B%U%C%/$r@_Dj$7!$%S%k%I$d%F%9%H$,@.8y$7$?(B
+$B$H$-$K8B$C$F!$%U%C%/$,?7$?$JJQ99$r%f!<%6$N(Bpull\empth{$B$G$-$k(B}$BJL$N%j%]%8%H(B
+$B%j$K(Bpush$B$9$k$h$&$K$9$k!%(B
+
+%In practice, putting a centralised bottleneck like this in place is
+%not often a good idea, and transaction visibility has nothing to do
+%with the problem.  As the size of a project---and the time it takes to
+%build and test---grows, you rapidly run into a wall with this ``try
+%before you buy'' approach, where you have more changesets to test than
+%time in which to deal with them.  The inevitable result is frustration
+%on the part of all involved.
 
-In practice, putting a centralised bottleneck like this in place is
-not often a good idea, and transaction visibility has nothing to do
-with the problem.  As the size of a project---and the time it takes to
-build and test---grows, you rapidly run into a wall with this ``try
-before you buy'' approach, where you have more changesets to test than
-time in which to deal with them.  The inevitable result is frustration
-on the part of all involved.
+$B<B:]>e$O!$$3$N$h$&$K=8Cf$7$?%\%H%k%M%C%/$rCV$/$3$H$ONI$$9M$($H$O8@$($:!$(B
+$B%H%i%s%6%/%7%g%s$N2D;k@-$OA4$/$J$$!%%W%m%8%'%/%H$N%5%$%:$*$h$S%S%k%I$H%F(B
+$B%9%H$KMW$9$k;~4V$,A}2C$9$k$K=>$C$F!$$3$N$h$&$J(B``$B;vA0$K;n$9(B''$B<jK!$OJI$KFM(B
+$B$-Ev$?$k!%%F%9%H$K;H$($k;~4V$G;+$-@Z$l$J$$$[$I$N%A%'%s%8%;%C%H$r;n$5$J$1(B
+$B$l$P$J$i$J$/$J$k$+$i$G$"$k!%%U%i%9%H%l!<%7%g%s$,Cy$k$N$OHr$1$i$l$J$$$@$m(B
+$B$&!%(B
 
-An approach that scales better is to get people to build and test
-before they push, then run automated builds and tests centrally
-\emph{after} a push, to be sure all is well.  The advantage of this
-approach is that it does not impose a limit on the rate at which the
-repository can accept changes.
+%An approach that scales better is to get people to build and test
+%before they push, then run automated builds and tests centrally
+%\emph{after} a push, to be sure all is well.  The advantage of this
+%approach is that it does not impose a limit on the rate at which the
+%repository can accept changes.
+
+$B$h$j%9%1!<%k$9$k<jK!$O!$3+H/<T$K(Bpush$BA0$N%S%k%I$H%F%9%H$r$5$;$k$3$H$G$"(B
+$B$k!%Cf1{$G<+F0$K$h$k%S%k%I$H%F%9%H$r9T$&$N$O!$(Bpush\emph{$B8e(B}$B$K!$A4$F$KLdBj(B
+$B$,$J$$$3$H$r3NG'$9$k$?$a$K9T$&!%$3$N%"%W%m!<%A$NMxE@$O%j%]%8%H%j$,JQ99$r(B
+$B<u$1F~$l$k%Z!<%9$K2?$b@)8B$r2]$5$J$$$3$H$G$"$k!%(B
 
 %\section{A short tutorial on using hooks}
 \section{$B%U%C%/$N;HMQK!(B}