1.1 --- a/en/00book.tex	Thu Apr 05 23:28:06 2007 -0700
     1.2 +++ b/en/00book.tex	Mon Apr 16 14:19:31 2007 -0700
     1.3 @@ -44,6 +44,7 @@
     1.4  \include{daily}
     1.5  \include{collab}
     1.6  \include{filenames}
     1.7 +\include{branch}
     1.8  \include{undo}
     1.9  \include{hook}
    1.10  \include{template}

     2.1 --- a/en/Makefile	Thu Apr 05 23:28:06 2007 -0700
     2.2 +++ b/en/Makefile	Mon Apr 16 14:19:31 2007 -0700
     2.3 @@ -5,6 +5,7 @@
     2.4  	99book.bib \
     2.5  	99defs.tex \
     2.6  	build_id.tex \
     2.7 +	branch.tex \
     2.8  	cmdref.tex \
     2.9  	collab.tex \
    2.10  	concepts.tex \

     3.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     3.2 +++ b/en/branch.tex	Mon Apr 16 14:19:31 2007 -0700
     3.3 @@ -0,0 +1,9 @@
     3.4 +\chapter{Managing branchy development}
     3.5 +\label{chap:branch}
     3.6 +
     3.7 +
     3.8 +
     3.9 +%%% Local Variables: 
    3.10 +%%% mode: latex
    3.11 +%%% TeX-master: "00book"
    3.12 +%%% End: 

     4.1 --- a/en/collab.tex	Thu Apr 05 23:28:06 2007 -0700
     4.2 +++ b/en/collab.tex	Mon Apr 16 14:19:31 2007 -0700
     4.3 @@ -257,6 +257,35 @@
     4.4  of development is astounding.  And yet Linux is a highly successful,
     4.5  well-regarded piece of software.
     4.6  
     4.7 +\subsection{Pull-only versus shared-push collaboration}
     4.8 +
     4.9 +A perpetual source of heat in the open source community is whether a
    4.10 +development model in which people only ever pull changes from others
    4.11 +is ``better than'' one in which multiple people can push changes to a
    4.12 +shared repository.
    4.13 +
    4.14 +Typically, the backers of the shared-push model use tools that
    4.15 +actively enforce this approach.  If you're using a centralised
    4.16 +revision control tool such as Subversion, there's no way to make a
    4.17 +choice over which model you'll use: the tool gives you shared-push,
    4.18 +and if you want to do anything else, you'll have to roll your own
    4.19 +approach on top (such as applying a patch by hand).
    4.20 +
    4.21 +A good distributed revision control tool, such as Mercurial, will
    4.22 +support both models.  You and your collaborators can then structure
    4.23 +how you work together based on your own needs and preferences, not on
    4.24 +what contortions your tools force you into.
    4.25 +
    4.26 +\subsection{Where collaboration meets branch management}
    4.27 +
    4.28 +Once you and your team set up some shared repositories and start
    4.29 +propagating changes back and forth between local and shared repos, you
    4.30 +begin to face a related, but slightly different challenge: that of
    4.31 +managing the multiple directions in which your team may be moving at
    4.32 +once.  Even though this subject is intimately related to how your team
    4.33 +collaborates, it's dense enough to merit treatment of its own, in
    4.34 +chapter~\ref{chap:branch}.
    4.35 +
    4.36  \section{The technical side of sharing}
    4.37  
    4.38  \subsection{Informal sharing with \hgcmd{serve}}