diff en/collab.tex @ 187:b60e2de6dbc3

Add chapter on branch management.
author Bryan O'Sullivan <bos@serpentine.com>
date Mon, 16 Apr 2007 14:19:31 -0700
parents 7b812c428074
children 8b599dcca584
line wrap: on
line diff
--- 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}}