comparison ja/hook.tex @ 377:4a9d7e24b915

a bit more hook.tex

376:9f7812b79c70

$B%8%;%C%H$N%a%?%G!<%?$rFI$`$3$H$N$G$-$k%?%$%`%&%#%s%I%&$,3+$/!%$3$N%A%'%s(B
$B%8%;%C%H$O$^$@1JB3E*$J$b$N$K$J$C$F$*$i$:!$=>$C$F<B:_$9$k$H9M$($k$Y$-$G$O(B
$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.

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.

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.

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.

%\section{A short tutorial on using hooks}
\section{$B%U%C%/$N;HMQK!(B}
\label{sec:hook:simple}

377:4a9d7e24b915

$B%8%;%C%H$N%a%?%G!<%?$rFI$`$3$H$N$G$-$k%?%$%`%&%#%s%I%&$,3+$/!%$3$N%A%'%s(B
$B%8%;%C%H$O$^$@1JB3E*$J$b$N$K$J$C$F$*$i$:!$=>$C$F<B:_$9$k$H9M$($k$Y$-$G$O(B
$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.

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

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

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

$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}
\label{sec:hook:simple}