changeset 187:b60e2de6dbc3

Add chapter on branch management.

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

--- a/en/Makefile	Thu Apr 05 23:28:06 2007 -0700
+++ b/en/Makefile	Mon Apr 16 14:19:31 2007 -0700
@@ -5,6 +5,7 @@
 	99book.bib \
 	99defs.tex \
 	build_id.tex \
+	branch.tex \
 	cmdref.tex \
 	collab.tex \
 	concepts.tex \

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

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