hgbook
changeset 187:b60e2de6dbc3
Add chapter on branch management.
author | Bryan O'Sullivan <bos@serpentine.com> |
---|---|
date | Mon Apr 16 14:19:31 2007 -0700 (2007-04-16) |
parents | 7b812c428074 |
children | 3c6c5b551c96 |
files | en/00book.tex en/Makefile en/branch.tex en/collab.tex |
line diff
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}}