hgbook
view en/collab.tex @ 184:7b812c428074
Document the ssh protocol, URL syntax, and configuration.
| author | Bryan O'Sullivan <bos@serpentine.com> |
|---|---|
| date | Thu Apr 05 23:28:06 2007 -0700 (2007-04-05) |
| parents | 5fc4a45c069f |
| children | b60e2de6dbc3 |
line source
1 \chapter{Collaborating with other people}
2 \label{cha:collab}
4 As a completely decentralised tool, Mercurial doesn't impose any
5 policy on how people ought to work with each other. However, if
6 you're new to distributed revision control, it helps to have some
7 tools and examples in mind when you're thinking about possible
8 workflow models.
10 \section{Collaboration models}
12 With a suitably flexible tool, making decisions about workflow is much
13 more of a social engineering challenge than a technical one.
14 Mercurial imposes few limitations on how you can structure the flow of
15 work in a project, so it's up to you and your group to set up and live
16 with a model that matches your own particular needs.
18 \subsection{Factors to keep in mind}
20 The most important aspect of any model that you must keep in mind is
21 how well it matches the needs and capabilities of the people who will
22 be using it. This might seem self-evident; even so, you still can't
23 afford to forget it for a moment.
25 I once put together a workflow model that seemed to make perfect sense
26 to me, but that caused a considerable amount of consternation and
27 strife within my development team. In spite of my attempts to explain
28 why we needed a complex set of branches, and how changes ought to flow
29 between them, a few team members revolted. Even though they were
30 smart people, they didn't want to pay attention to the constraints we
31 were operating under, or face the consequences of those constraints in
32 the details of the model that I was advocating.
34 Don't sweep foreseeable social or technical problems under the rug.
35 Whatever scheme you put into effect, you should plan for mistakes and
36 problem scenarios. Consider adding automated machinery to prevent, or
37 quickly recover from, trouble that you can anticipate. As an example,
38 if you intend to have a branch with not-for-release changes in it,
39 you'd do well to think early about the possibility that someone might
40 accidentally merge those changes into a release branch. You could
41 avoid this particular problem by writing a hook that prevents changes
42 from being merged from an inappropriate branch.
44 \subsection{Informal anarchy}
46 I wouldn't suggest an ``anything goes'' approach as something
47 sustainable, but it's a model that's easy to grasp, and it works
48 perfectly well in a few unusual situations.
50 As one example, many projects have a loose-knit group of collaborators
51 who rarely physically meet each other. Some groups like to overcome
52 the isolation of working at a distance by organising occasional
53 ``sprints''. In a sprint, a number of people get together in a single
54 location (a company's conference room, a hotel meeting room, that kind
55 of place) and spend several days more or less locked in there, hacking
56 intensely on a handful of projects.
58 A sprint is the perfect place to use the \hgcmd{serve} command, since
59 \hgcmd{serve} does not requires any fancy server infrastructure. You
60 can get started with \hgcmd{serve} in moments, by reading
61 section~\ref{sec:collab:serve} below. Then simply tell the person
62 next to you that you're running a server, send the URL to them in an
63 instant message, and you immediately have a quick-turnaround way to
64 work together. They can type your URL into their web browser and
65 quickly review your changes; or they can pull a bugfix from you and
66 verify it; or they can clone a branch containing a new feature and try
67 it out.
69 The charm, and the problem, with doing things in an ad hoc fashion
70 like this is that only people who know about your changes, and where
71 they are, can see them. Such an informal approach simply doesn't
72 scale beyond a handful people, because each individual needs to know
73 about $n$ different repositories to pull from.
75 \subsection{A single central repository}
77 For smaller projects migrating from a centralised revision control
78 tool, perhaps the easiest way to get started is to have changes flow
79 through a single shared central repository. This is also the
80 most common ``building block'' for more ambitious workflow schemes.
82 Contributors start by cloning a copy of this repository. They can
83 pull changes from it whenever they need to, and some (perhaps all)
84 developers have permission to push a change back when they're ready
85 for other people to see it.
87 Under this model, it can still often make sense for people to pull
88 changes directly from each other, without going through the central
89 repository. Consider a case in which I have a tentative bug fix, but
90 I am worried that if I were to publish it to the central repository,
91 it might subsequently break everyone else's trees as they pull it. To
92 reduce the potential for damage, I can ask you to clone my repository
93 into a temporary repository of your own and test it. This lets us put
94 off publishing the potentially unsafe change until it has had a little
95 testing.
97 In this kind of scenario, people usually use the \command{ssh}
98 protocol to securely push changes to the central repository, as
99 documented in section~\ref{sec:collab:ssh}. It's also usual to
100 publish a read-only copy of the repository over HTTP using CGI, as in
101 section~\ref{sec:collab:cgi}. Publishing over HTTP satisfies the
102 needs of people who don't have push access, and those who want to use
103 web browsers to browse the repository's history.
105 \subsection{Working with multiple branches}
107 Projects of any significant size naturally tend to make progress on
108 several fronts simultaneously. In the case of software, it's common
109 for a project to go through periodic official releases. A release
110 might then go into ``maintenance mode'' for a while after its first
111 publication; maintenance releases tend to contain only bug fixes, not
112 new features. In parallel with these maintenance releases, one or
113 more future releases may be under development. People normally use
114 the word ``branch'' to refer to one of these many slightly different
115 directions in which development is proceeding.
117 Mercurial is particularly well suited to managing a number of
118 simultaneous, but not identical, branches. Each ``development
119 direction'' can live in its own central repository, and you can merge
120 changes from one to another as the need arises. Because repositories
121 are independent of each other, unstable changes in a development
122 branch will never affect a stable branch unless someone explicitly
123 merges those changes in.
125 Here's an example of how this can work in practice. Let's say you
126 have one ``main branch'' on a central server.
127 \interaction{branching.init}
128 People clone it, make changes locally, test them, and push them back.
130 Once the main branch reaches a release milestone, you can use the
131 \hgcmd{tag} command to give a permanent name to the milestone
132 revision.
133 \interaction{branching.tag}
134 Let's say some ongoing development occurs on the main branch.
135 \interaction{branching.main}
136 Using the tag that was recorded at the milestone, people who clone
137 that repository at any time in the future can use \hgcmd{update} to
138 get a copy of the working directory exactly as it was when that tagged
139 revision was committed.
140 \interaction{branching.update}
142 In addition, immediately after the main branch is tagged, someone can
143 then clone the main branch on the server to a new ``stable'' branch,
144 also on the server.
145 \interaction{branching.clone}
147 Someone who needs to make a change to the stable branch can then clone
148 \emph{that} repository, make their changes, commit, and push their
149 changes back there.
150 \interaction{branching.stable}
151 Because Mercurial repositories are independent, and Mercurial doesn't
152 move changes around automatically, the stable and main branches are
153 \emph{isolated} from each other. The changes that you made on the
154 main branch don't ``leak'' to the stable branch, and vice versa.
156 You'll often want all of your bugfixes on the stable branch to show up
157 on the main branch, too. Rather than rewrite a bugfix on the main
158 branch, you can simply pull and merge changes from the stable to the
159 main branch, and Mercurial will bring those bugfixes in for you.
160 \interaction{branching.merge}
161 The main branch will still contain changes that are not on the stable
162 branch, but it will also contain all of the bugfixes from the stable
163 branch. The stable branch remains unaffected by these changes.
165 \subsection{Feature branches}
167 For larger projects, an effective way to manage change is to break up
168 a team into smaller groups. Each group has a shared branch of its
169 own, cloned from a single ``master'' branch used by the entire
170 project. People working on an individual branch are typically quite
171 isolated from developments on other branches.
173 \begin{figure}[ht]
174 \centering
175 \grafix{feature-branches}
176 \caption{Feature branches}
177 \label{fig:collab:feature-branches}
178 \end{figure}
180 When a particular feature is deemed to be in suitable shape, someone
181 on that feature team pulls and merges from the master branch into the
182 feature branch, then pushes back up to the master branch.
184 \subsection{The release train}
186 Some projects are organised on a ``train'' basis: a release is
187 scheduled to happen every few months, and whatever features are ready
188 when the ``train'' is ready to leave are allowed in.
190 This model resembles working with feature branches. The difference is
191 that when a feature branch misses a train, someone on the feature team
192 pulls and merges the changes that went out on that train release into
193 the feature branch, and the team continues its work on top of that
194 release so that their feature can make the next release.
196 \subsection{The Linux kernel model}
198 The development of the Linux kernel has a shallow hierarchical
199 structure, surrounded by a cloud of apparent chaos. Because most
200 Linux developers use \command{git}, a distributed revision control
201 tool with capabilities similar to Mercurial, it's useful to describe
202 the way work flows in that environment; if you like the ideas, the
203 approach translates well across tools.
205 At the center of the community sits Linus Torvalds, the creator of
206 Linux. He publishes a single source repository that is considered the
207 ``authoritative'' current tree by the entire developer community.
208 Anyone can clone Linus's tree, but he is very choosy about whose trees
209 he pulls from.
211 Linus has a number of ``trusted lieutenants''. As a general rule, he
212 pulls whatever changes they publish, in most cases without even
213 reviewing those changes. Some of those lieutenants are generally
214 agreed to be ``maintainers'', responsible for specific subsystems
215 within the kernel. If a random kernel hacker wants to make a change
216 to a subsystem that they want to end up in Linus's tree, they must
217 find out who the subsystem's maintainer is, and ask that maintainer to
218 take their change. If the maintainer reviews their changes and agrees
219 to take them, they'll pass them along to Linus in due course.
221 Individual lieutenants have their own approaches to reviewing,
222 accepting, and publishing changes; and for deciding when to feed them
223 to Linus. In addition, there are several well known branches that
224 people use for different purposes. For example, a few people maintain
225 ``stable'' repositories of older versions of the kernel, to which they
226 apply critical fixes as needed. Some maintainers publish multiple
227 trees: one for experimental changes; one for changes that they are
228 about to feed upstream; and so on. Others just publish a single
229 tree.
231 This model has two notable features. The first is that it's ``pull
232 only''. You have to ask, convince, or beg another developer to take a
233 change from you, because there are almost no trees to which more than
234 one person can push, and there's no way to push changes into a tree
235 that someone else controls.
237 The second is that it's based on reputation and acclaim. If you're an
238 unknown, Linus will probably ignore changes from you without even
239 responding. But a subsystem maintainer will probably review them, and
240 will likely take them if they pass their criteria for suitability.
241 The more ``good'' changes you contribute to a maintainer, the more
242 likely they are to trust your judgment and accept your changes. If
243 you're well-known and maintain a long-lived branch for something Linus
244 hasn't yet accepted, people with similar interests may pull your
245 changes regularly to keep up with your work.
247 Reputation and acclaim don't necessarily cross subsystem or ``people''
248 boundaries. If you're a respected but specialised storage hacker, and
249 you try to fix a networking bug, that change will receive a level of
250 scrutiny from a network maintainer comparable to a change from a
251 complete stranger.
253 To people who come from more orderly project backgrounds, the
254 comparatively chaotic Linux kernel development process often seems
255 completely insane. It's subject to the whims of individuals; people
256 make sweeping changes whenever they deem it appropriate; and the pace
257 of development is astounding. And yet Linux is a highly successful,
258 well-regarded piece of software.
260 \section{The technical side of sharing}
262 \subsection{Informal sharing with \hgcmd{serve}}
263 \label{sec:collab:serve}
265 Mercurial's \hgcmd{serve} command is wonderfully suited to small,
266 tight-knit, and fast-paced group environments. It also provides a
267 great way to get a feel for using Mercurial commands over a network.
269 Run \hgcmd{serve} inside a repository, and in under a second it will
270 bring up a specialised HTTP server; this will accept connections from
271 any client, and serve up data for that repository until you terminate
272 it. Anyone who knows the URL of the server you just started, and can
273 talk to your computer over the network, can then use a web browser or
274 Mercurial to read data from that repository. A URL for a
275 \hgcmd{serve} instance running on a laptop is likely to look something
276 like \Verb|http://my-laptop.local:8000/|.
278 The \hgcmd{serve} command is \emph{not} a general-purpose web server.
279 It can do only two things:
280 \begin{itemize}
281 \item Allow people to browse the history of the repository it's
282 serving, from their normal web browsers.
283 \item Speak Mercurial's wire protocol, so that people can
284 \hgcmd{clone} or \hgcmd{pull} changes from that repository.
285 \end{itemize}
286 In particular, \hgcmd{serve} won't allow remote users to \emph{modify}
287 your repository. It's intended for read-only use.
289 If you're getting started with Mercurial, there's nothing to prevent
290 you from using \hgcmd{serve} to serve up a repository on your own
291 computer, then use commands like \hgcmd{clone}, \hgcmd{incoming}, and
292 so on to talk to that server as if the repository was hosted remotely.
293 This can help you to quickly get acquainted with using commands on
294 network-hosted repositories.
296 \subsubsection{A few things to keep in mind}
298 Because it provides unauthenticated read access to all clients, you
299 should only use \hgcmd{serve} in an environment where you either don't
300 care, or have complete control over, who can access your network and
301 pull data from your repository.
303 The \hgcmd{serve} command knows nothing about any firewall software
304 you might have installed on your system or network. It cannot detect
305 or control your firewall software. If other people are unable to talk
306 to a running \hgcmd{serve} instance, the second thing you should do
307 (\emph{after} you make sure that they're using the correct URL) is
308 check your firewall configuration.
310 By default, \hgcmd{serve} listens for incoming connections on
311 port~8000. If another process is already listening on the port you
312 want to use, you can specify a different port to listen on using the
313 \hgopt{serve}{-p} option.
315 Normally, when \hgcmd{serve} starts, it prints no output, which can be
316 a bit unnerving. If you'd like to confirm that it is indeed running
317 correctly, and find out what URL you should send to your
318 collaborators, start it with the \hggopt{-v} option.
320 \subsection{Using the Secure Shell (ssh) protocol}
321 \label{sec:collab:ssh}
323 You can pull and push changes securely over a network connection using
324 the Secure Shell (\texttt{ssh}) protocol. To use this successfully,
325 you may have to do a little bit of configuration on the client or
326 server sides.
328 If you're not familiar with ssh, it's a network protocol that lets you
329 securely communicate with another computer. To use it with Mercurial,
330 you'll be setting up one or more user accounts on a server so that
331 remote users can log in and execute commands.
333 (If you \emph{are} familiar with ssh, you'll probably find some of the
334 material that follows to be elementary in nature.)
336 \subsubsection{How to read and write ssh URLs}
338 An ssh URL tends to look like this:
339 \begin{codesample2}
340 ssh://bos@hg.serpentine.com:22/hg/hgbook
341 \end{codesample2}
342 \begin{enumerate}
343 \item The ``\texttt{ssh://}'' part tells Mercurial to use the ssh
344 protocol.
345 \item The ``\texttt{bos@}'' component indicates what username to log
346 into the server as. You can leave this out if the remote username
347 is the same as your local username.
348 \item The ``\texttt{hg.serpentine.com}'' gives the hostname of the
349 server to log into.
350 \item The ``:22'' identifies the port number to connect to the server
351 on. The default port is~22, so you only need to specify this part
352 if you're \emph{not} using port~22.
353 \item The remainder of the URL is the local path to the repository on
354 the server.
355 \end{enumerate}
357 There's plenty of scope for confusion with the path component of ssh
358 URLs, as there is no standard way for tools to interpret it. Some
359 programs behave differently than others when dealing with these paths.
360 This isn't an ideal situation, but it's unlikely to change. Please
361 read the following paragraphs carefully.
363 Mercurial treats the path to a repository on the server as relative to
364 the remote user's home directory. For example, if user \texttt{foo}
365 on the server has a home directory of \dirname{/home/foo}, then an ssh
366 URL that contains a path component of \dirname{bar}
367 \emph{really} refers to the directory \dirname{/home/foo/bar}.
369 If you want to specify a path relative to another user's home
370 directory, you can use a path that starts with a tilde character
371 followed by the user's name (let's call them \texttt{otheruser}), like
372 this.
373 \begin{codesample2}
374 ssh://server/~otheruser/hg/repo
375 \end{codesample2}
377 And if you really want to specify an \emph{absolute} path on the
378 server, begin the path component with two slashes, as in this example.
379 \begin{codesample2}
380 ssh://server//absolute/path
381 \end{codesample2}
383 \subsubsection{Finding an ssh client for your system}
385 Almost every Unix-like system comes with OpenSSH preinstalled. If
386 you're using such a system, run \Verb|which ssh| to find out if
387 the \command{ssh} command is installed (it's usually in
388 \dirname{/usr/bin}). In the unlikely event that it isn't present,
389 take a look at your system documentation to figure out how to install
390 it.
392 On Windows, you'll first need to choose download a suitable ssh
393 client. There are two alternatives.
394 \begin{itemize}
395 \item Simon Tatham's excellent PuTTY package~\cite{web:putty} provides
396 a complete suite of ssh client commands.
397 \item If you have a high tolerance for pain, you can use the Cygwin
398 port of OpenSSH.
399 \end{itemize}
400 In either case, you'll need to edit your \hgini\ file to tell
401 Mercurial where to find the actual client command. For example, if
402 you're using PuTTY, you'll need to use the \command{plink} command as
403 a command-line ssh client.
404 \begin{codesample2}
405 [ui]
406 ssh = C:/path/to/plink.exe -ssh -i "C:/path/to/my/private/key"
407 \end{codesample2}
409 \begin{note}
410 The path to \command{plink} shouldn't contain any whitespace
411 characters, or Mercurial may not be able to run it correctly (so
412 putting it in \dirname{C:\\Program Files} is probably not be a good
413 idea).
414 \end{note}
416 \subsubsection{Generating a key pair}
418 To avoid the need to repetitively type a password every time you need
419 to use your ssh client, I recommend generating a key pair. On a
420 Unix-like system, the \command{ssh-keygen} command will do the trick.
421 On Windows, if you're using PuTTY, the \command{puttygen} command is
422 what you'll need.
424 When you generate a key pair, it's usually \emph{highly} advisable to
425 protect it with a passphrase. (The only time that you might not want
426 to do this id when you're using the ssh protocol for automated tasks
427 on a secure network.)
429 Simply generating a key pair isn't enough, however. You'll need to
430 add the public key to the set of authorised keys for whatever user
431 you're logging in remotely as. For servers using OpenSSH (the vast
432 majority), this will mean adding the public key to a list in a file
433 called \sfilename{authorized\_keys} in their \sdirname{.ssh}
434 directory.
436 On a Unix-like system, your public key will have a \filename{.pub}
437 extension. If you're using \command{puttygen} on Windows, you can
438 save the public key to a file of your choosing, or paste it from the
439 window it's displayed in straight into the
440 \sfilename{authorized\_keys} file.
442 \subsubsection{Using an authentication agent}
444 An authentication agent is a daemon that stores passphrases in memory
445 (so it will forget passphrases if you log out and log back in again).
446 An ssh client will notice if it's running, and query it for a
447 passphrase. If there's no authentication agent running, or the agent
448 doesn't store the necessary passphrase, you'll have to type your
449 passphrase every time Mercurial tries to communicate with a server on
450 your behalf (e.g.~whenever you pull or push changes).
452 The downside of storing passphrases in an agent is that it's possible
453 for a well-prepared attacker to recover the plain text of your
454 passphrases, in some cases even if your system has been power-cycled.
455 You should make your own judgment as to whether this is an acceptable
456 risk. It certainly saves a lot of repeated typing.
458 On Unix-like systems, the agent is called \command{ssh-agent}, and
459 it's often run automatically for you when you log in. You'll need to
460 use the \command{ssh-add} command to add passphrases to the agent's
461 store. On Windows, if you're using PuTTY, the \command{pageant}
462 command acts as the agent. It adds an icon to your system tray that
463 will let you manage stored passphrases.
465 \subsubsection{Configuring the server side properly}
467 Because ssh can be fiddly to set up if you're new to it, there's a
468 variety of things that can go wrong. Add Mercurial on top, and
469 there's plenty more scope for head-scratching. Most of these
470 potential problems occur on the server side, not the client side. The
471 good news is that once you've gotten a configuration working, it will
472 usually continue to work indefinitely.
474 Before you try using Mercurial to talk to an ssh server, it's best to
475 make sure that you can use the normal \command{ssh} or \command{putty}
476 command to talk to the server first. If you run into problems with
477 using these commands directly, Mercurial surely won't work. Worse, it
478 will obscure the underlying problem. Any time you want to debug
479 ssh-related Mercurial problems, you should drop back to making sure
480 that plain ssh client commands work first, \emph{before} you worry
481 about whether there's a problem with Mercurial.
483 The first thing to be sure of on the server side is that you can
484 actually log in from another machine at all. If you can't use
485 \command{ssh} or \command{putty} to log in, the error message you get
486 may give you a few hints as to what's wrong. The most common problems
487 are as follows.
488 \begin{itemize}
489 \item If you get a ``connection refused'' error, either there isn't an
490 SSH daemon running on the server at all, or it's inaccessible due to
491 firewall configuration.
492 \item If you get a ``no route to host'' error, you either have an
493 incorrect address for the server or a seriously locked down firewall
494 that won't admit its existence at all.
495 \item If you get a ``permission denied'' error, you may have mistyped
496 the username on the server, or you could have mistyped your key's
497 passphrase or the remote user's password.
498 \end{itemize}
499 In summary, if you're having trouble talking to the server's ssh
500 daemon, first make sure that one is running at all. On many systems
501 it will be installed, but disabled, by default. Once you're done with
502 this step, you should then check that the server's firewall is
503 configured to allow incoming connections on the port the ssh daemon is
504 listening on (usually~22). Don't worry about more exotic
505 possibilities for misconfiguration until you've checked these two
506 first.
508 If you're using an authentication agent on the client side to store
509 passphrases for your keys, you ought to be able to log into the server
510 without being prompted for a passphrase or a password. If you're
511 prompted for a passphrase, there are a few possible culprits.
512 \begin{itemize}
513 \item You might have forgotten to use \command{ssh-add} or
514 \command{pageant} to store the passphrase.
515 \item You might have stored the passphrase for the wrong key.
516 \end{itemize}
517 If you're being prompted for the remote user's password, there are
518 another few possible problems to check.
519 \begin{itemize}
520 \item Either the user's home directory or their \sdirname{.ssh}
521 directory might have excessively liberal permissions. As a result,
522 the ssh daemon will not trust or read their
523 \sfilename{authorized\_keys} file. For example, a group-writable
524 home or \sdirname{.ssh} directory will often cause this symptom.
525 \item The user's \sfilename{authorized\_keys} file may have a problem.
526 If anyone other than the user owns or can write to that file, the
527 ssh daemon will not trust or read it.
528 \end{itemize}
530 In the ideal world, you should be able to run the following command
531 successfully, and it should print exactly one line of output, the
532 current date and time.
533 \begin{codesample2}
534 ssh myserver date
535 \end{codesample2}
537 If on your server you have login scripts that print banners or other
538 junk even when running non-interactive commands like this, you should
539 fix them before you continue, so that they only print output if
540 they're run interactively. Otherwise these banners will at least
541 clutter up Mercurial's output. Worse, they could potentially cause
542 problems with running Mercurial commands remotely. (The usual way to
543 see if a login script is running in an interactive shell is to check
544 the return code from the command \Verb|tty -s|.)
546 Once you've verified that plain old ssh is working with your server,
547 the next step is to ensure that Mercurial runs on the server. The
548 following command should run successfully:
549 \begin{codesample2}
550 ssh myserver hg version
551 \end{codesample2}
552 If you see an error message instead of normal \hgcmd{version} output,
553 this is usually because you haven't installed Mercurial to
554 \dirname{/usr/bin}. Don't worry if this is the case; you don't need
555 to do that. But you should check for a few possible problems.
556 \begin{itemize}
557 \item Is Mercurial really installed on the server at all? I know this
558 sounds trivial, but it's worth checking!
559 \item Maybe your shell's search path (usually set via the \envar{PATH}
560 environment variable) is simply misconfigured.
561 \item Perhaps your \envar{PATH} environment variable is only being set
562 to point to the location of the \command{hg} executable if the login
563 session is interactive. This can happen if you're setting the path
564 in the wrong shell login script. See your shell's documentation for
565 details.
566 \item The \envar{PYTHONPATH} environment variable may need to contain
567 the path to the Mercurial Python modules. It might not be set at
568 all; it could be incorrect; or it may be set only if the login is
569 interactive.
570 \end{itemize}
572 If you can run \hgcmd{version} over an ssh connection, well done!
573 You've got the server and client sorted out. You should now be able
574 to use Mercurial to access repositories hosted by that username on
575 that server. If you run into problems with Mercurial and ssh at this
576 point, try using the \hggopt{--debug} option to get a clearer picture
577 of what's going on.
579 \subsubsection{Using compression with ssh}
581 Mercurial does not compress data when it uses the ssh protocol,
582 because the ssh protocol can transparently compress data. However,
583 the default behaviour of ssh clients is \emph{not} to request
584 compression.
586 Over any network other than a fast LAN (even a wireless network),
587 using compression is likely to significantly speed up Mercurial's
588 network operations. For example, over a WAN, someone measured
589 compression as reducing the amount of time required to clone a
590 particularly large repository from~51 minutes to~17 minutes.
592 Both \command{ssh} and \command{plink} accept a \cmdopt{ssh}{-C}
593 option which turns on compression. You can easily edit your \hgrc\ to
594 enable compression for all of Mercurial's uses of the ssh protocol.
595 \begin{codesample2}
596 [ui]
597 ssh = ssh -C
598 \end{codesample2}
600 \subsection{Serving over HTTP with a CGI script}
601 \label{sec:collab:cgi}
605 %%% Local Variables:
606 %%% mode: latex
607 %%% TeX-master: "00book"
608 %%% End: