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