hgbook

changeset 201:80fc720338a5

Mention use of hooks to defend against propagation of bad changes.
author Bryan O'Sullivan <bos@serpentine.com>
date Wed Apr 18 15:48:00 2007 -0700 (2007-04-18)
parents 9bba958be4c6
children 6f167e644762
files en/undo.tex
line diff
     1.1 --- a/en/undo.tex	Wed Apr 18 11:55:39 2007 -0700
     1.2 +++ b/en/undo.tex	Wed Apr 18 15:48:00 2007 -0700
     1.3 @@ -457,6 +457,26 @@
     1.4  \texttt{examples} directory works, but doesn't handle merge
     1.5  changesets.  Kind of an important omission.
     1.6  
     1.7 +\subsection{Protect yourself from ``escaped'' changes}
     1.8 +
     1.9 +If you've committed some changes to your local repository and they've
    1.10 +been pushed or pulled somewhere else, this isn't necessarily a
    1.11 +disaster.  You can protect yourself ahead of time against some classes
    1.12 +of bad changeset.  This is particularly easy if your team usually
    1.13 +pulls changes from a central repository.
    1.14 +
    1.15 +By configuring some hooks on that repository to validate incoming
    1.16 +changesets (see chapter~\ref{chap:hook}), you can automatically
    1.17 +prevent some kinds of bad changeset from being pushed to the central
    1.18 +repository at all.  With such a configuration in place, some kinds of
    1.19 +bad changeset will naturally tend to ``die out'' because they can't
    1.20 +propagate into the central repository.  Better yet, this happens
    1.21 +without any need for explicit intervention.
    1.22 +
    1.23 +For instance, an incoming change hook that verifies that a changeset
    1.24 +will actually compile can prevent people from inadvertantly ``breaking
    1.25 +the build''.
    1.26 +
    1.27  \section{Finding the source of a bug}
    1.28  \label{sec:undo:bisect}
    1.29