Mercurial > hgbook
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}}