hgbook
changeset 220:0ca9045035f7
Advantages for open source and commercial tools.
author | Bryan O'Sullivan <bos@serpentine.com> |
---|---|
date | Mon May 14 15:22:32 2007 -0700 (2007-05-14) |
parents | 15a6fd2ba582 |
children | 680b7b055aa7 |
files | en/intro.tex |
line diff
1.1 --- a/en/intro.tex Mon May 14 11:20:34 2007 -0700 1.2 +++ b/en/intro.tex Mon May 14 15:22:32 2007 -0700 1.3 @@ -226,6 +226,8 @@ 1.4 something that is relatively rare compared with local operations. If 1.5 you have a far-flung team of collaborators, this may be significant. 1.6 1.7 +\subsection{Advantages for open source projects} 1.8 + 1.9 If you take a shine to an open source project and decide that you 1.10 would like to start hacking on it, and that project uses a distributed 1.11 revision control tool, you are at once a peer with the people who 1.12 @@ -239,13 +241,82 @@ 1.13 be at risk of corruption any time you try to update your client's view 1.14 of the repository. 1.15 1.16 -\subsection{For open source projects} 1.17 - 1.18 -\subsection{For commercial projects} 1.19 - 1.20 -\subsection{Myths about distributed revision control} 1.21 - 1.22 -\subsubsection{Distributed tools encourage projects to fork} 1.23 +\subsubsection{The forking non-problem} 1.24 + 1.25 +It has been suggested that distributed revision control tools pose 1.26 +some sort of risk to open source projects because they make it easy to 1.27 +``fork'' the development of a project. A fork happens when there are 1.28 +differences in opinion or attitude between groups of developers that 1.29 +cause them to decide that they can't work together any longer. Each 1.30 +side takes a more or less complete copy of the project's source code, 1.31 +and goes off in its own direction. 1.32 + 1.33 +Sometimes the camps in a fork decide to reconcile their differences. 1.34 +With a centralised revision control system, the \emph{technical} 1.35 +process of reconciliation is painful, and has to be performed largely 1.36 +by hand. You have to decide whose revision history is going to 1.37 +``win'', and graft the other team's changes into the tree somehow. 1.38 +This usually loses some or all of one side's revision history. 1.39 + 1.40 +What distributed tools do with respect to forking is they make forking 1.41 +the \emph{only} way to develop a project. Every single change that 1.42 +you make is potentially a fork point. The great strength of this 1.43 +approach is that a distributed revision control tool has to be really 1.44 +good at \emph{merging} forks, because forks are absolutely 1.45 +fundamental: they happen all the time. 1.46 + 1.47 +If every piece of work that everybody does, all the time, is framed in 1.48 +terms of forking and merging, then what the open source world refers 1.49 +to as a ``fork'' becomes \emph{purely} a social issue. If anything, 1.50 +distributed tools \emph{lower} the likelihood of a fork: 1.51 +\begin{itemize} 1.52 +\item They eliminate the social distinction that centralised tools 1.53 + impose: that between insiders (people with commit access) and 1.54 + outsiders (people without). 1.55 +\item They make it easier to reconcile after a social fork, because 1.56 + all that's involved from the perspective of the revision control 1.57 + software is just another merge. 1.58 +\end{itemize} 1.59 + 1.60 +Some people resist distributed tools because they want to retain tight 1.61 +control over their projects, and they believe that centralised tools 1.62 +give them this control. However, if you're of this belief, and you 1.63 +publish your CVS or Subversion repositories publically, there are 1.64 +plenty of tools available that can pull out your entire project's 1.65 +history (albeit slowly) and recreate it somewhere that you don't 1.66 +control. So while your control in this case is illusory, you are 1.67 +foregoing the ability to fluidly collaborate with whatever people feel 1.68 +compelled to mirror and fork your history. 1.69 + 1.70 +\subsection{Advantages for commercial projects} 1.71 + 1.72 +Many commercial projects are undertaken by teams that are scattered 1.73 +across the globe. Contributors who are far from a central server will 1.74 +see slower command execution and perhaps less reliability. Commercial 1.75 +revision control systems attempt to ameliorate these problems with 1.76 +remote-site replication add-ons that are typically expensive to buy 1.77 +and cantankerous to administer. A distributed system doesn't suffer 1.78 +from these problems in the first place. Better yet, you can easily 1.79 +set up multiple authoritative servers, say one per site, so that 1.80 +there's no redundant communication between repositories over expensive 1.81 +long-haul network links. 1.82 + 1.83 +Centralised revision control systems tend to have relatively low 1.84 +scalability. It's not unusual for an expensive centralised system to 1.85 +fall over under the combined load of just a few dozen concurrent 1.86 +users. Once again, the typical response tends to be an expensive and 1.87 +clunky replication facility. Since the load on a central server---if 1.88 +you have one at all---is orders of magnitude lower with a distributed 1.89 +tool (because all of the data is replicated everywhere), a single 1.90 +cheap server can handle the needs of a much larger team, and 1.91 +replication to balance load becomes a simple matter of scripting. 1.92 + 1.93 +If you have an employee in the field, troubleshooting a problem at a 1.94 +customer's site, they'll benefit from distributed revision control. 1.95 +The tool will let them generate custom builds, try different fixes in 1.96 +isolation from each other, and search efficiently through history for 1.97 +the sources of bugs and regressions in the customer's environment, all 1.98 +without needing to connect to your company's network. 1.99 1.100 \section{Why choose Mercurial?} 1.101