hgbook

annotate en/ch06-collab.xml @ 561:21c62e09b99f

find changesets by author, revision, files, or words in the commit message
Typo and spelling corrections. Removed tex tags.
author Ori Avtalion <ori@avtalion.name>
date Thu Mar 05 21:52:23 2009 +0200 (2009-03-05)
parents dbe91bb622d8
children 8fcd44708f41
rev   line source
bos@559 1 <!-- vim: set filetype=docbkxml shiftwidth=2 autoindent expandtab tw=77 : -->
bos@559 2
bos@559 3 <chapter id="cha:collab">
bos@559 4 <title>Collaborating with other people</title>
bos@559 5
bos@559 6 <para>As a completely decentralised tool, Mercurial doesn't impose
bos@559 7 any policy on how people ought to work with each other. However,
bos@559 8 if you're new to distributed revision control, it helps to have
bos@559 9 some tools and examples in mind when you're thinking about
bos@559 10 possible workflow models.</para>
bos@559 11
bos@559 12 <sect1>
bos@559 13 <title>Mercurial's web interface</title>
bos@559 14
bos@559 15 <para>Mercurial has a powerful web interface that provides several
bos@559 16 useful capabilities.</para>
bos@559 17
bos@559 18 <para>For interactive use, the web interface lets you browse a
bos@559 19 single repository or a collection of repositories. You can view
bos@559 20 the history of a repository, examine each change (comments and
bos@559 21 diffs), and view the contents of each directory and file.</para>
bos@559 22
bos@559 23 <para>Also for human consumption, the web interface provides an
bos@559 24 RSS feed of the changes in a repository. This lets you
bos@559 25 <quote>subscribe</quote> to a repository using your favourite
bos@559 26 feed reader, and be automatically notified of activity in that
bos@559 27 repository as soon as it happens. I find this capability much
bos@559 28 more convenient than the model of subscribing to a mailing list
bos@559 29 to which notifications are sent, as it requires no additional
bos@559 30 configuration on the part of whoever is serving the
bos@559 31 repository.</para>
bos@559 32
bos@559 33 <para>The web interface also lets remote users clone a repository,
bos@559 34 pull changes from it, and (when the server is configured to
bos@559 35 permit it) push changes back to it. Mercurial's HTTP tunneling
bos@559 36 protocol aggressively compresses data, so that it works
bos@559 37 efficiently even over low-bandwidth network connections.</para>
bos@559 38
bos@559 39 <para>The easiest way to get started with the web interface is to
bos@559 40 use your web browser to visit an existing repository, such as
bos@559 41 the master Mercurial repository at <ulink
bos@559 42 url="http://www.selenic.com/repo/hg?style=gitweb">http://www.selenic.com/repo/hg?style=gitweb</ulink>.</para>
bos@559 43
bos@559 44 <para>If you're interested in providing a web interface to your
bos@559 45 own repositories, Mercurial provides two ways to do this. The
bos@559 46 first is using the <command role="hg-cmd">hg serve</command>
bos@559 47 command, which is best suited to short-term
bos@559 48 <quote>lightweight</quote> serving. See section <xref
bos@559 49 linkend="sec:collab:serve"/> below for details of how to use
bos@559 50 this command. If you have a long-lived repository that you'd
bos@559 51 like to make permanently available, Mercurial has built-in
bos@559 52 support for the CGI (Common Gateway Interface) standard, which
bos@559 53 all common web servers support. See section <xref
bos@559 54 linkend="sec:collab:cgi"/> for details of CGI
bos@559 55 configuration.</para>
bos@559 56
bos@559 57 </sect1>
bos@559 58 <sect1>
bos@559 59 <title>Collaboration models</title>
bos@559 60
bos@559 61 <para>With a suitably flexible tool, making decisions about
bos@559 62 workflow is much more of a social engineering challenge than a
bos@559 63 technical one. Mercurial imposes few limitations on how you can
bos@559 64 structure the flow of work in a project, so it's up to you and
bos@559 65 your group to set up and live with a model that matches your own
bos@559 66 particular needs.</para>
bos@559 67
bos@559 68 <sect2>
bos@559 69 <title>Factors to keep in mind</title>
bos@559 70
bos@559 71 <para>The most important aspect of any model that you must keep
bos@559 72 in mind is how well it matches the needs and capabilities of
bos@559 73 the people who will be using it. This might seem
bos@559 74 self-evident; even so, you still can't afford to forget it for
bos@559 75 a moment.</para>
bos@559 76
bos@559 77 <para>I once put together a workflow model that seemed to make
bos@559 78 perfect sense to me, but that caused a considerable amount of
bos@559 79 consternation and strife within my development team. In spite
bos@559 80 of my attempts to explain why we needed a complex set of
bos@559 81 branches, and how changes ought to flow between them, a few
bos@559 82 team members revolted. Even though they were smart people,
bos@559 83 they didn't want to pay attention to the constraints we were
bos@559 84 operating under, or face the consequences of those constraints
bos@559 85 in the details of the model that I was advocating.</para>
bos@559 86
bos@559 87 <para>Don't sweep foreseeable social or technical problems under
bos@559 88 the rug. Whatever scheme you put into effect, you should plan
bos@559 89 for mistakes and problem scenarios. Consider adding automated
bos@559 90 machinery to prevent, or quickly recover from, trouble that
bos@559 91 you can anticipate. As an example, if you intend to have a
bos@559 92 branch with not-for-release changes in it, you'd do well to
bos@559 93 think early about the possibility that someone might
bos@559 94 accidentally merge those changes into a release branch. You
bos@559 95 could avoid this particular problem by writing a hook that
bos@559 96 prevents changes from being merged from an inappropriate
bos@559 97 branch.</para>
bos@559 98
bos@559 99 </sect2>
bos@559 100 <sect2>
bos@559 101 <title>Informal anarchy</title>
bos@559 102
bos@559 103 <para>I wouldn't suggest an <quote>anything goes</quote>
bos@559 104 approach as something sustainable, but it's a model that's
bos@559 105 easy to grasp, and it works perfectly well in a few unusual
bos@559 106 situations.</para>
bos@559 107
bos@559 108 <para>As one example, many projects have a loose-knit group of
bos@559 109 collaborators who rarely physically meet each other. Some
bos@559 110 groups like to overcome the isolation of working at a distance
bos@559 111 by organising occasional <quote>sprints</quote>. In a sprint,
bos@559 112 a number of people get together in a single location (a
bos@559 113 company's conference room, a hotel meeting room, that kind of
bos@559 114 place) and spend several days more or less locked in there,
bos@559 115 hacking intensely on a handful of projects.</para>
bos@559 116
bos@559 117 <para>A sprint is the perfect place to use the <command
bos@559 118 role="hg-cmd">hg serve</command> command, since <command
jon@560 119 role="hg-cmd">hg serve</command> does not require any fancy
bos@559 120 server infrastructure. You can get started with <command
bos@559 121 role="hg-cmd">hg serve</command> in moments, by reading
bos@559 122 section <xref linkend="sec:collab:serve"/> below. Then simply
bos@559 123 tell
bos@559 124 the person next to you that you're running a server, send the
bos@559 125 URL to them in an instant message, and you immediately have a
bos@559 126 quick-turnaround way to work together. They can type your URL
bos@559 127 into their web browser and quickly review your changes; or
bos@559 128 they can pull a bugfix from you and verify it; or they can
bos@559 129 clone a branch containing a new feature and try it out.</para>
bos@559 130
bos@559 131 <para>The charm, and the problem, with doing things in an ad hoc
bos@559 132 fashion like this is that only people who know about your
bos@559 133 changes, and where they are, can see them. Such an informal
bos@559 134 approach simply doesn't scale beyond a handful people, because
bos@559 135 each individual needs to know about $n$ different repositories
bos@559 136 to pull from.</para>
bos@559 137
bos@559 138 </sect2>
bos@559 139 <sect2>
bos@559 140 <title>A single central repository</title>
bos@559 141
bos@559 142 <para>For smaller projects migrating from a centralised revision
bos@559 143 control tool, perhaps the easiest way to get started is to
bos@559 144 have changes flow through a single shared central repository.
bos@559 145 This is also the most common <quote>building block</quote> for
bos@559 146 more ambitious workflow schemes.</para>
bos@559 147
bos@559 148 <para>Contributors start by cloning a copy of this repository.
bos@559 149 They can pull changes from it whenever they need to, and some
bos@559 150 (perhaps all) developers have permission to push a change back
bos@559 151 when they're ready for other people to see it.</para>
bos@559 152
bos@559 153 <para>Under this model, it can still often make sense for people
bos@559 154 to pull changes directly from each other, without going
bos@559 155 through the central repository. Consider a case in which I
bos@559 156 have a tentative bug fix, but I am worried that if I were to
bos@559 157 publish it to the central repository, it might subsequently
bos@559 158 break everyone else's trees as they pull it. To reduce the
bos@559 159 potential for damage, I can ask you to clone my repository
bos@559 160 into a temporary repository of your own and test it. This
bos@559 161 lets us put off publishing the potentially unsafe change until
bos@559 162 it has had a little testing.</para>
bos@559 163
bos@559 164 <para>In this kind of scenario, people usually use the
bos@559 165 <command>ssh</command> protocol to securely push changes to
bos@559 166 the central repository, as documented in section <xref
bos@559 167 linkend="sec:collab:ssh"/>. It's also
bos@559 168 usual to publish a read-only copy of the repository over HTTP
bos@559 169 using CGI, as in section <xref linkend="sec:collab:cgi"/>.
bos@559 170 Publishing over HTTP
bos@559 171 satisfies the needs of people who don't have push access, and
bos@559 172 those who want to use web browsers to browse the repository's
bos@559 173 history.</para>
bos@559 174
bos@559 175 </sect2>
bos@559 176 <sect2>
bos@559 177 <title>Working with multiple branches</title>
bos@559 178
bos@559 179 <para>Projects of any significant size naturally tend to make
bos@559 180 progress on several fronts simultaneously. In the case of
bos@559 181 software, it's common for a project to go through periodic
bos@559 182 official releases. A release might then go into
bos@559 183 <quote>maintenance mode</quote> for a while after its first
bos@559 184 publication; maintenance releases tend to contain only bug
bos@559 185 fixes, not new features. In parallel with these maintenance
bos@559 186 releases, one or more future releases may be under
bos@559 187 development. People normally use the word
bos@559 188 <quote>branch</quote> to refer to one of these many slightly
bos@559 189 different directions in which development is
bos@559 190 proceeding.</para>
bos@559 191
bos@559 192 <para>Mercurial is particularly well suited to managing a number
bos@559 193 of simultaneous, but not identical, branches. Each
bos@559 194 <quote>development direction</quote> can live in its own
bos@559 195 central repository, and you can merge changes from one to
bos@559 196 another as the need arises. Because repositories are
bos@559 197 independent of each other, unstable changes in a development
bos@559 198 branch will never affect a stable branch unless someone
bos@559 199 explicitly merges those changes in.</para>
bos@559 200
bos@559 201 <para>Here's an example of how this can work in practice. Let's
bos@559 202 say you have one <quote>main branch</quote> on a central
bos@559 203 server. <!-- &interaction.branching.init; --> People clone it,
bos@559 204 make changes locally, test them, and push them back.</para>
bos@559 205
bos@559 206 <para>Once the main branch reaches a release milestone, you can
bos@559 207 use the <command role="hg-cmd">hg tag</command> command to
bos@559 208 give a permanent name to the milestone revision. <!--
bos@559 209 &interaction.branching.tag; --> Let's say some ongoing
bos@559 210 development occurs on the main branch. <!--
bos@559 211 &interaction.branching.main; --> Using the tag that was
bos@559 212 recorded at the milestone, people who clone that repository at
bos@559 213 any time in the future can use <command role="hg-cmd">hg
bos@559 214 update</command> to get a copy of the working directory
bos@559 215 exactly as it was when that tagged revision was committed.
bos@559 216 <!-- &interaction.branching.update; --></para>
bos@559 217
bos@559 218 <para>In addition, immediately after the main branch is tagged,
bos@559 219 someone can then clone the main branch on the server to a new
bos@559 220 <quote>stable</quote> branch, also on the server. <!--
bos@559 221 &interaction.branching.clone; --></para>
bos@559 222
bos@559 223 <para>Someone who needs to make a change to the stable branch
bos@559 224 can then clone <emphasis>that</emphasis> repository, make
bos@559 225 their changes, commit, and push their changes back there. <!--
bos@559 226 &interaction.branching.stable; --> Because Mercurial
bos@559 227 repositories are independent, and Mercurial doesn't move
bos@559 228 changes around automatically, the stable and main branches are
bos@559 229 <emphasis>isolated</emphasis> from each other. The changes
bos@559 230 that you made on the main branch don't <quote>leak</quote> to
bos@559 231 the stable branch, and vice versa.</para>
bos@559 232
bos@559 233 <para>You'll often want all of your bugfixes on the stable
bos@559 234 branch to show up on the main branch, too. Rather than
bos@559 235 rewrite a bugfix on the main branch, you can simply pull and
bos@559 236 merge changes from the stable to the main branch, and
bos@559 237 Mercurial will bring those bugfixes in for you. <!--
bos@559 238 &interaction.branching.merge; --> The main branch will still
bos@559 239 contain changes that are not on the stable branch, but it will
bos@559 240 also contain all of the bugfixes from the stable branch. The
bos@559 241 stable branch remains unaffected by these changes.</para>
bos@559 242
bos@559 243 </sect2>
bos@559 244 <sect2>
bos@559 245 <title>Feature branches</title>
bos@559 246
bos@559 247 <para>For larger projects, an effective way to manage change is
bos@559 248 to break up a team into smaller groups. Each group has a
bos@559 249 shared branch of its own, cloned from a single
bos@559 250 <quote>master</quote> branch used by the entire project.
bos@559 251 People working on an individual branch are typically quite
bos@559 252 isolated from developments on other branches.</para>
bos@559 253
bos@559 254 <informalfigure id="fig:collab:feature-branches">
bos@559 255 <mediaobject><imageobject><imagedata
bos@559 256 fileref="feature-branches"/></imageobject><textobject><phrase>XXX
bos@559 257 add text</phrase></textobject><caption><para>Feature
bos@559 258 branches</para></caption></mediaobject>
bos@559 259 </informalfigure>
bos@559 260
bos@559 261 <para>When a particular feature is deemed to be in suitable
bos@559 262 shape, someone on that feature team pulls and merges from the
bos@559 263 master branch into the feature branch, then pushes back up to
bos@559 264 the master branch.</para>
bos@559 265
bos@559 266 </sect2>
bos@559 267 <sect2>
bos@559 268 <title>The release train</title>
bos@559 269
bos@559 270 <para>Some projects are organised on a <quote>train</quote>
bos@559 271 basis: a release is scheduled to happen every few months, and
bos@559 272 whatever features are ready when the <quote>train</quote> is
bos@559 273 ready to leave are allowed in.</para>
bos@559 274
bos@559 275 <para>This model resembles working with feature branches. The
bos@559 276 difference is that when a feature branch misses a train,
bos@559 277 someone on the feature team pulls and merges the changes that
bos@559 278 went out on that train release into the feature branch, and
bos@559 279 the team continues its work on top of that release so that
bos@559 280 their feature can make the next release.</para>
bos@559 281
bos@559 282 </sect2>
bos@559 283 <sect2>
bos@559 284 <title>The Linux kernel model</title>
bos@559 285
bos@559 286 <para>The development of the Linux kernel has a shallow
bos@559 287 hierarchical structure, surrounded by a cloud of apparent
bos@559 288 chaos. Because most Linux developers use
bos@559 289 <command>git</command>, a distributed revision control tool
bos@559 290 with capabilities similar to Mercurial, it's useful to
bos@559 291 describe the way work flows in that environment; if you like
bos@559 292 the ideas, the approach translates well across tools.</para>
bos@559 293
bos@559 294 <para>At the center of the community sits Linus Torvalds, the
bos@559 295 creator of Linux. He publishes a single source repository
bos@559 296 that is considered the <quote>authoritative</quote> current
bos@559 297 tree by the entire developer community. Anyone can clone
bos@559 298 Linus's tree, but he is very choosy about whose trees he pulls
bos@559 299 from.</para>
bos@559 300
bos@559 301 <para>Linus has a number of <quote>trusted lieutenants</quote>.
bos@559 302 As a general rule, he pulls whatever changes they publish, in
bos@559 303 most cases without even reviewing those changes. Some of
bos@559 304 those lieutenants are generally agreed to be
bos@559 305 <quote>maintainers</quote>, responsible for specific
bos@559 306 subsystems within the kernel. If a random kernel hacker wants
bos@559 307 to make a change to a subsystem that they want to end up in
bos@559 308 Linus's tree, they must find out who the subsystem's
bos@559 309 maintainer is, and ask that maintainer to take their change.
bos@559 310 If the maintainer reviews their changes and agrees to take
bos@559 311 them, they'll pass them along to Linus in due course.</para>
bos@559 312
bos@559 313 <para>Individual lieutenants have their own approaches to
bos@559 314 reviewing, accepting, and publishing changes; and for deciding
bos@559 315 when to feed them to Linus. In addition, there are several
bos@559 316 well known branches that people use for different purposes.
bos@559 317 For example, a few people maintain <quote>stable</quote>
bos@559 318 repositories of older versions of the kernel, to which they
bos@559 319 apply critical fixes as needed. Some maintainers publish
bos@559 320 multiple trees: one for experimental changes; one for changes
bos@559 321 that they are about to feed upstream; and so on. Others just
bos@559 322 publish a single tree.</para>
bos@559 323
bos@559 324 <para>This model has two notable features. The first is that
bos@559 325 it's <quote>pull only</quote>. You have to ask, convince, or
bos@559 326 beg another developer to take a change from you, because there
bos@559 327 are almost no trees to which more than one person can push,
bos@559 328 and there's no way to push changes into a tree that someone
bos@559 329 else controls.</para>
bos@559 330
bos@559 331 <para>The second is that it's based on reputation and acclaim.
bos@559 332 If you're an unknown, Linus will probably ignore changes from
bos@559 333 you without even responding. But a subsystem maintainer will
bos@559 334 probably review them, and will likely take them if they pass
bos@559 335 their criteria for suitability. The more <quote>good</quote>
bos@559 336 changes you contribute to a maintainer, the more likely they
bos@559 337 are to trust your judgment and accept your changes. If you're
bos@559 338 well-known and maintain a long-lived branch for something
bos@559 339 Linus hasn't yet accepted, people with similar interests may
bos@559 340 pull your changes regularly to keep up with your work.</para>
bos@559 341
bos@559 342 <para>Reputation and acclaim don't necessarily cross subsystem
bos@559 343 or <quote>people</quote> boundaries. If you're a respected
bos@559 344 but specialised storage hacker, and you try to fix a
bos@559 345 networking bug, that change will receive a level of scrutiny
bos@559 346 from a network maintainer comparable to a change from a
bos@559 347 complete stranger.</para>
bos@559 348
bos@559 349 <para>To people who come from more orderly project backgrounds,
bos@559 350 the comparatively chaotic Linux kernel development process
bos@559 351 often seems completely insane. It's subject to the whims of
bos@559 352 individuals; people make sweeping changes whenever they deem
bos@559 353 it appropriate; and the pace of development is astounding.
bos@559 354 And yet Linux is a highly successful, well-regarded piece of
bos@559 355 software.</para>
bos@559 356
bos@559 357 </sect2>
bos@559 358 <sect2>
bos@559 359 <title>Pull-only versus shared-push collaboration</title>
bos@559 360
bos@559 361 <para>A perpetual source of heat in the open source community is
bos@559 362 whether a development model in which people only ever pull
bos@559 363 changes from others is <quote>better than</quote> one in which
bos@559 364 multiple people can push changes to a shared
bos@559 365 repository.</para>
bos@559 366
bos@559 367 <para>Typically, the backers of the shared-push model use tools
bos@559 368 that actively enforce this approach. If you're using a
bos@559 369 centralised revision control tool such as Subversion, there's
bos@559 370 no way to make a choice over which model you'll use: the tool
bos@559 371 gives you shared-push, and if you want to do anything else,
bos@559 372 you'll have to roll your own approach on top (such as applying
bos@559 373 a patch by hand).</para>
bos@559 374
bos@559 375 <para>A good distributed revision control tool, such as
bos@559 376 Mercurial, will support both models. You and your
bos@559 377 collaborators can then structure how you work together based
bos@559 378 on your own needs and preferences, not on what contortions
bos@559 379 your tools force you into.</para>
bos@559 380
bos@559 381 </sect2>
bos@559 382 <sect2>
bos@559 383 <title>Where collaboration meets branch management</title>
bos@559 384
bos@559 385 <para>Once you and your team set up some shared repositories and
bos@559 386 start propagating changes back and forth between local and
bos@559 387 shared repos, you begin to face a related, but slightly
bos@559 388 different challenge: that of managing the multiple directions
bos@559 389 in which your team may be moving at once. Even though this
bos@559 390 subject is intimately related to how your team collaborates,
bos@559 391 it's dense enough to merit treatment of its own, in chapter
bos@559 392 <xref linkend="chap:branch"/>.</para>
bos@559 393
bos@559 394 </sect2>
bos@559 395 </sect1>
bos@559 396 <sect1>
bos@559 397 <title>The technical side of sharing</title>
bos@559 398
bos@559 399 <para>The remainder of this chapter is devoted to the question of
bos@559 400 serving data to your collaborators.</para>
bos@559 401
bos@559 402 </sect1>
bos@559 403 <sect1 id="sec:collab:serve">
bos@559 404 <title>Informal sharing with <command role="hg-cmd">hg
bos@559 405 serve</command></title>
bos@559 406
bos@559 407 <para>Mercurial's <command role="hg-cmd">hg serve</command>
bos@559 408 command is wonderfully suited to small, tight-knit, and
bos@559 409 fast-paced group environments. It also provides a great way to
bos@559 410 get a feel for using Mercurial commands over a network.</para>
bos@559 411
bos@559 412 <para>Run <command role="hg-cmd">hg serve</command> inside a
bos@559 413 repository, and in under a second it will bring up a specialised
bos@559 414 HTTP server; this will accept connections from any client, and
bos@559 415 serve up data for that repository until you terminate it.
bos@559 416 Anyone who knows the URL of the server you just started, and can
bos@559 417 talk to your computer over the network, can then use a web
bos@559 418 browser or Mercurial to read data from that repository. A URL
bos@559 419 for a <command role="hg-cmd">hg serve</command> instance running
bos@559 420 on a laptop is likely to look something like
bos@559 421 <literal>http://my-laptop.local:8000/</literal>.</para>
bos@559 422
bos@559 423 <para>The <command role="hg-cmd">hg serve</command> command is
bos@559 424 <emphasis>not</emphasis> a general-purpose web server. It can do
bos@559 425 only two things:</para>
bos@559 426 <itemizedlist>
bos@559 427 <listitem><para>Allow people to browse the history of the
bos@559 428 repository it's serving, from their normal web
bos@559 429 browsers.</para>
bos@559 430 </listitem>
bos@559 431 <listitem><para>Speak Mercurial's wire protocol, so that people
bos@559 432 can <command role="hg-cmd">hg clone</command> or <command
bos@559 433 role="hg-cmd">hg pull</command> changes from that
bos@559 434 repository.</para>
bos@559 435 </listitem></itemizedlist>
bos@559 436 <para>In particular, <command role="hg-cmd">hg serve</command>
bos@559 437 won't allow remote users to <emphasis>modify</emphasis> your
bos@559 438 repository. It's intended for read-only use.</para>
bos@559 439
bos@559 440 <para>If you're getting started with Mercurial, there's nothing to
bos@559 441 prevent you from using <command role="hg-cmd">hg serve</command>
bos@559 442 to serve up a repository on your own computer, then use commands
bos@559 443 like <command role="hg-cmd">hg clone</command>, <command
bos@559 444 role="hg-cmd">hg incoming</command>, and so on to talk to that
bos@559 445 server as if the repository was hosted remotely. This can help
bos@559 446 you to quickly get acquainted with using commands on
bos@559 447 network-hosted repositories.</para>
bos@559 448
bos@559 449 <sect2>
bos@559 450 <title>A few things to keep in mind</title>
bos@559 451
bos@559 452 <para>Because it provides unauthenticated read access to all
bos@559 453 clients, you should only use <command role="hg-cmd">hg
bos@559 454 serve</command> in an environment where you either don't
bos@559 455 care, or have complete control over, who can access your
bos@559 456 network and pull data from your repository.</para>
bos@559 457
bos@559 458 <para>The <command role="hg-cmd">hg serve</command> command
bos@559 459 knows nothing about any firewall software you might have
bos@559 460 installed on your system or network. It cannot detect or
bos@559 461 control your firewall software. If other people are unable to
bos@559 462 talk to a running <command role="hg-cmd">hg serve</command>
bos@559 463 instance, the second thing you should do
bos@559 464 (<emphasis>after</emphasis> you make sure that they're using
bos@559 465 the correct URL) is check your firewall configuration.</para>
bos@559 466
bos@559 467 <para>By default, <command role="hg-cmd">hg serve</command>
bos@559 468 listens for incoming connections on port 8000. If another
bos@559 469 process is already listening on the port you want to use, you
bos@559 470 can specify a different port to listen on using the <option
bos@559 471 role="hg-opt-serve">-p</option> option.</para>
bos@559 472
bos@559 473 <para>Normally, when <command role="hg-cmd">hg serve</command>
bos@559 474 starts, it prints no output, which can be a bit unnerving. If
bos@559 475 you'd like to confirm that it is indeed running correctly, and
bos@559 476 find out what URL you should send to your collaborators, start
bos@559 477 it with the <option role="hg-opt-global">-v</option>
bos@559 478 option.</para>
bos@559 479
bos@559 480 </sect2>
bos@559 481 </sect1>
bos@559 482 <sect1 id="sec:collab:ssh">
bos@559 483 <title>Using the Secure Shell (ssh) protocol</title>
bos@559 484
bos@559 485 <para>You can pull and push changes securely over a network
bos@559 486 connection using the Secure Shell (<literal>ssh</literal>)
bos@559 487 protocol. To use this successfully, you may have to do a little
bos@559 488 bit of configuration on the client or server sides.</para>
bos@559 489
bos@559 490 <para>If you're not familiar with ssh, it's a network protocol
bos@559 491 that lets you securely communicate with another computer. To
bos@559 492 use it with Mercurial, you'll be setting up one or more user
bos@559 493 accounts on a server so that remote users can log in and execute
bos@559 494 commands.</para>
bos@559 495
bos@559 496 <para>(If you <emphasis>are</emphasis> familiar with ssh, you'll
bos@559 497 probably find some of the material that follows to be elementary
bos@559 498 in nature.)</para>
bos@559 499
bos@559 500 <sect2>
bos@559 501 <title>How to read and write ssh URLs</title>
bos@559 502
bos@559 503 <para>An ssh URL tends to look like this:</para>
bos@559 504 <programlisting>ssh://bos@hg.serpentine.com:22/hg/hgbook</programlisting>
bos@559 505 <orderedlist>
bos@559 506 <listitem><para>The <quote><literal>ssh://</literal></quote>
bos@559 507 part tells Mercurial to use the ssh protocol.</para>
bos@559 508 </listitem>
bos@559 509 <listitem><para>The <quote><literal>bos@</literal></quote>
bos@559 510 component indicates what username to log into the server
bos@559 511 as. You can leave this out if the remote username is the
bos@559 512 same as your local username.</para>
bos@559 513 </listitem>
bos@559 514 <listitem><para>The
bos@559 515 <quote><literal>hg.serpentine.com</literal></quote> gives
bos@559 516 the hostname of the server to log into.</para>
bos@559 517 </listitem>
bos@559 518 <listitem><para>The <quote>:22</quote> identifies the port
bos@559 519 number to connect to the server on. The default port is
bos@559 520 22, so you only need to specify this part if you're
bos@559 521 <emphasis>not</emphasis> using port 22.</para>
bos@559 522 </listitem>
bos@559 523 <listitem><para>The remainder of the URL is the local path to
bos@559 524 the repository on the server.</para>
bos@559 525 </listitem></orderedlist>
bos@559 526
bos@559 527 <para>There's plenty of scope for confusion with the path
bos@559 528 component of ssh URLs, as there is no standard way for tools
bos@559 529 to interpret it. Some programs behave differently than others
bos@559 530 when dealing with these paths. This isn't an ideal situation,
bos@559 531 but it's unlikely to change. Please read the following
bos@559 532 paragraphs carefully.</para>
bos@559 533
bos@559 534 <para>Mercurial treats the path to a repository on the server as
bos@559 535 relative to the remote user's home directory. For example, if
bos@559 536 user <literal>foo</literal> on the server has a home directory
bos@559 537 of <filename class="directory">/home/foo</filename>, then an
bos@559 538 ssh URL that contains a path component of <filename
bos@559 539 class="directory">bar</filename> <emphasis>really</emphasis>
bos@559 540 refers to the directory <filename
bos@559 541 class="directory">/home/foo/bar</filename>.</para>
bos@559 542
bos@559 543 <para>If you want to specify a path relative to another user's
bos@559 544 home directory, you can use a path that starts with a tilde
bos@559 545 character followed by the user's name (let's call them
bos@559 546 <literal>otheruser</literal>), like this.</para>
bos@559 547 <programlisting>ssh://server/~otheruser/hg/repo</programlisting>
bos@559 548
bos@559 549 <para>And if you really want to specify an
bos@559 550 <emphasis>absolute</emphasis> path on the server, begin the
bos@559 551 path component with two slashes, as in this example.</para>
bos@559 552 <programlisting>ssh://server//absolute/path</programlisting>
bos@559 553
bos@559 554 </sect2>
bos@559 555 <sect2>
bos@559 556 <title>Finding an ssh client for your system</title>
bos@559 557
bos@559 558 <para>Almost every Unix-like system comes with OpenSSH
bos@559 559 preinstalled. If you're using such a system, run
bos@559 560 <literal>which ssh</literal> to find out if the
bos@559 561 <command>ssh</command> command is installed (it's usually in
bos@559 562 <filename class="directory">/usr/bin</filename>). In the
bos@559 563 unlikely event that it isn't present, take a look at your
bos@559 564 system documentation to figure out how to install it.</para>
bos@559 565
bos@559 566 <para>On Windows, you'll first need to download a suitable ssh
bos@559 567 client. There are two alternatives.</para>
bos@559 568 <itemizedlist>
bos@559 569 <listitem><para>Simon Tatham's excellent PuTTY package
bos@559 570 <citation>web:putty</citation> provides a complete suite
bos@559 571 of ssh client commands.</para>
bos@559 572 </listitem>
bos@559 573 <listitem><para>If you have a high tolerance for pain, you can
bos@559 574 use the Cygwin port of OpenSSH.</para>
bos@559 575 </listitem></itemizedlist>
bos@559 576 <para>In either case, you'll need to edit your \hgini\ file to
bos@559 577 tell Mercurial where to find the actual client command. For
bos@559 578 example, if you're using PuTTY, you'll need to use the
bos@559 579 <command>plink</command> command as a command-line ssh
bos@559 580 client.</para>
bos@559 581 <programlisting>[ui] ssh = C:/path/to/plink.exe -ssh -i
bos@559 582 "C:/path/to/my/private/key"</programlisting>
bos@559 583
bos@559 584 <note>
bos@559 585 <para> The path to <command>plink</command> shouldn't contain
bos@559 586 any whitespace characters, or Mercurial may not be able to
bos@559 587 run it correctly (so putting it in <filename
bos@559 588 class="directory">C:\\Program Files</filename> is probably
bos@559 589 not a good idea).</para>
bos@559 590 </note>
bos@559 591
bos@559 592 </sect2>
bos@559 593 <sect2>
bos@559 594 <title>Generating a key pair</title>
bos@559 595
bos@559 596 <para>To avoid the need to repetitively type a password every
bos@559 597 time you need to use your ssh client, I recommend generating a
bos@559 598 key pair. On a Unix-like system, the
bos@559 599 <command>ssh-keygen</command> command will do the trick. On
bos@559 600 Windows, if you're using PuTTY, the
bos@559 601 <command>puttygen</command> command is what you'll
bos@559 602 need.</para>
bos@559 603
bos@559 604 <para>When you generate a key pair, it's usually
bos@559 605 <emphasis>highly</emphasis> advisable to protect it with a
bos@559 606 passphrase. (The only time that you might not want to do this
bos@559 607 is when you're using the ssh protocol for automated tasks on a
bos@559 608 secure network.)</para>
bos@559 609
bos@559 610 <para>Simply generating a key pair isn't enough, however.
bos@559 611 You'll need to add the public key to the set of authorised
bos@559 612 keys for whatever user you're logging in remotely as. For
bos@559 613 servers using OpenSSH (the vast majority), this will mean
bos@559 614 adding the public key to a list in a file called <filename
bos@559 615 role="special">authorized_keys</filename> in their <filename
bos@559 616 role="special" class="directory">.ssh</filename>
bos@559 617 directory.</para>
bos@559 618
bos@559 619 <para>On a Unix-like system, your public key will have a
bos@559 620 <filename>.pub</filename> extension. If you're using
bos@559 621 <command>puttygen</command> on Windows, you can save the
bos@559 622 public key to a file of your choosing, or paste it from the
bos@559 623 window it's displayed in straight into the <filename
bos@559 624 role="special">authorized_keys</filename> file.</para>
bos@559 625
bos@559 626 </sect2>
bos@559 627 <sect2>
bos@559 628 <title>Using an authentication agent</title>
bos@559 629
bos@559 630 <para>An authentication agent is a daemon that stores
bos@559 631 passphrases in memory (so it will forget passphrases if you
bos@559 632 log out and log back in again). An ssh client will notice if
bos@559 633 it's running, and query it for a passphrase. If there's no
bos@559 634 authentication agent running, or the agent doesn't store the
bos@559 635 necessary passphrase, you'll have to type your passphrase
bos@559 636 every time Mercurial tries to communicate with a server on
bos@559 637 your behalf (e.g. whenever you pull or push changes).</para>
bos@559 638
bos@559 639 <para>The downside of storing passphrases in an agent is that
bos@559 640 it's possible for a well-prepared attacker to recover the
bos@559 641 plain text of your passphrases, in some cases even if your
bos@559 642 system has been power-cycled. You should make your own
bos@559 643 judgment as to whether this is an acceptable risk. It
bos@559 644 certainly saves a lot of repeated typing.</para>
bos@559 645
bos@559 646 <para>On Unix-like systems, the agent is called
bos@559 647 <command>ssh-agent</command>, and it's often run automatically
bos@559 648 for you when you log in. You'll need to use the
bos@559 649 <command>ssh-add</command> command to add passphrases to the
bos@559 650 agent's store. On Windows, if you're using PuTTY, the
bos@559 651 <command>pageant</command> command acts as the agent. It adds
bos@559 652 an icon to your system tray that will let you manage stored
bos@559 653 passphrases.</para>
bos@559 654
bos@559 655 </sect2>
bos@559 656 <sect2>
bos@559 657 <title>Configuring the server side properly</title>
bos@559 658
bos@559 659 <para>Because ssh can be fiddly to set up if you're new to it,
bos@559 660 there's a variety of things that can go wrong. Add Mercurial
bos@559 661 on top, and there's plenty more scope for head-scratching.
bos@559 662 Most of these potential problems occur on the server side, not
bos@559 663 the client side. The good news is that once you've gotten a
bos@559 664 configuration working, it will usually continue to work
bos@559 665 indefinitely.</para>
bos@559 666
bos@559 667 <para>Before you try using Mercurial to talk to an ssh server,
bos@559 668 it's best to make sure that you can use the normal
bos@559 669 <command>ssh</command> or <command>putty</command> command to
bos@559 670 talk to the server first. If you run into problems with using
bos@559 671 these commands directly, Mercurial surely won't work. Worse,
bos@559 672 it will obscure the underlying problem. Any time you want to
bos@559 673 debug ssh-related Mercurial problems, you should drop back to
bos@559 674 making sure that plain ssh client commands work first,
bos@559 675 <emphasis>before</emphasis> you worry about whether there's a
bos@559 676 problem with Mercurial.</para>
bos@559 677
bos@559 678 <para>The first thing to be sure of on the server side is that
bos@559 679 you can actually log in from another machine at all. If you
bos@559 680 can't use <command>ssh</command> or <command>putty</command>
bos@559 681 to log in, the error message you get may give you a few hints
bos@559 682 as to what's wrong. The most common problems are as
bos@559 683 follows.</para>
bos@559 684 <itemizedlist>
bos@559 685 <listitem><para>If you get a <quote>connection refused</quote>
bos@559 686 error, either there isn't an SSH daemon running on the
bos@559 687 server at all, or it's inaccessible due to firewall
bos@559 688 configuration.</para>
bos@559 689 </listitem>
bos@559 690 <listitem><para>If you get a <quote>no route to host</quote>
bos@559 691 error, you either have an incorrect address for the server
bos@559 692 or a seriously locked down firewall that won't admit its
bos@559 693 existence at all.</para>
bos@559 694 </listitem>
bos@559 695 <listitem><para>If you get a <quote>permission denied</quote>
bos@559 696 error, you may have mistyped the username on the server,
bos@559 697 or you could have mistyped your key's passphrase or the
bos@559 698 remote user's password.</para>
bos@559 699 </listitem></itemizedlist>
bos@559 700 <para>In summary, if you're having trouble talking to the
bos@559 701 server's ssh daemon, first make sure that one is running at
bos@559 702 all. On many systems it will be installed, but disabled, by
bos@559 703 default. Once you're done with this step, you should then
bos@559 704 check that the server's firewall is configured to allow
bos@559 705 incoming connections on the port the ssh daemon is listening
bos@559 706 on (usually 22). Don't worry about more exotic possibilities
bos@559 707 for misconfiguration until you've checked these two
bos@559 708 first.</para>
bos@559 709
bos@559 710 <para>If you're using an authentication agent on the client side
bos@559 711 to store passphrases for your keys, you ought to be able to
bos@559 712 log into the server without being prompted for a passphrase or
bos@559 713 a password. If you're prompted for a passphrase, there are a
bos@559 714 few possible culprits.</para>
bos@559 715 <itemizedlist>
bos@559 716 <listitem><para>You might have forgotten to use
bos@559 717 <command>ssh-add</command> or <command>pageant</command>
bos@559 718 to store the passphrase.</para>
bos@559 719 </listitem>
bos@559 720 <listitem><para>You might have stored the passphrase for the
bos@559 721 wrong key.</para>
bos@559 722 </listitem></itemizedlist>
bos@559 723 <para>If you're being prompted for the remote user's password,
bos@559 724 there are another few possible problems to check.</para>
bos@559 725 <itemizedlist>
bos@559 726 <listitem><para>Either the user's home directory or their
bos@559 727 <filename role="special" class="directory">.ssh</filename>
bos@559 728 directory might have excessively liberal permissions. As
bos@559 729 a result, the ssh daemon will not trust or read their
bos@559 730 <filename role="special">authorized_keys</filename> file.
bos@559 731 For example, a group-writable home or <filename
bos@559 732 role="special" class="directory">.ssh</filename>
bos@559 733 directory will often cause this symptom.</para>
bos@559 734 </listitem>
bos@559 735 <listitem><para>The user's <filename
bos@559 736 role="special">authorized_keys</filename> file may have
bos@559 737 a problem. If anyone other than the user owns or can write
bos@559 738 to that file, the ssh daemon will not trust or read
bos@559 739 it.</para>
bos@559 740 </listitem></itemizedlist>
bos@559 741
bos@559 742 <para>In the ideal world, you should be able to run the
bos@559 743 following command successfully, and it should print exactly
bos@559 744 one line of output, the current date and time.</para>
bos@559 745 <programlisting>ssh myserver date</programlisting>
bos@559 746
bos@559 747 <para>If, on your server, you have login scripts that print
bos@559 748 banners or other junk even when running non-interactive
bos@559 749 commands like this, you should fix them before you continue,
bos@559 750 so that they only print output if they're run interactively.
bos@559 751 Otherwise these banners will at least clutter up Mercurial's
bos@559 752 output. Worse, they could potentially cause problems with
bos@559 753 running Mercurial commands remotely. Mercurial makes tries to
bos@559 754 detect and ignore banners in non-interactive
bos@559 755 <command>ssh</command> sessions, but it is not foolproof. (If
bos@559 756 you're editing your login scripts on your server, the usual
bos@559 757 way to see if a login script is running in an interactive
bos@559 758 shell is to check the return code from the command
bos@559 759 <literal>tty -s</literal>.)</para>
bos@559 760
bos@559 761 <para>Once you've verified that plain old ssh is working with
bos@559 762 your server, the next step is to ensure that Mercurial runs on
bos@559 763 the server. The following command should run
bos@559 764 successfully:</para>
bos@559 765 <programlisting>ssh myserver hg version</programlisting>
bos@559 766 <para>If you see an error message instead of normal <command
bos@559 767 role="hg-cmd">hg version</command> output, this is usually
bos@559 768 because you haven't installed Mercurial to <filename
bos@559 769 class="directory">/usr/bin</filename>. Don't worry if this
bos@559 770 is the case; you don't need to do that. But you should check
bos@559 771 for a few possible problems.</para>
bos@559 772 <itemizedlist>
bos@559 773 <listitem><para>Is Mercurial really installed on the server at
bos@559 774 all? I know this sounds trivial, but it's worth
bos@559 775 checking!</para>
bos@559 776 </listitem>
bos@559 777 <listitem><para>Maybe your shell's search path (usually set
bos@559 778 via the <envar>PATH</envar> environment variable) is
bos@559 779 simply misconfigured.</para>
bos@559 780 </listitem>
bos@559 781 <listitem><para>Perhaps your <envar>PATH</envar> environment
bos@559 782 variable is only being set to point to the location of the
bos@559 783 <command>hg</command> executable if the login session is
bos@559 784 interactive. This can happen if you're setting the path
bos@559 785 in the wrong shell login script. See your shell's
bos@559 786 documentation for details.</para>
bos@559 787 </listitem>
bos@559 788 <listitem><para>The <envar>PYTHONPATH</envar> environment
bos@559 789 variable may need to contain the path to the Mercurial
bos@559 790 Python modules. It might not be set at all; it could be
bos@559 791 incorrect; or it may be set only if the login is
bos@559 792 interactive.</para>
bos@559 793 </listitem></itemizedlist>
bos@559 794
bos@559 795 <para>If you can run <command role="hg-cmd">hg version</command>
bos@559 796 over an ssh connection, well done! You've got the server and
bos@559 797 client sorted out. You should now be able to use Mercurial to
bos@559 798 access repositories hosted by that username on that server.
bos@559 799 If you run into problems with Mercurial and ssh at this point,
bos@559 800 try using the <option role="hg-opt-global">--debug</option>
bos@559 801 option to get a clearer picture of what's going on.</para>
bos@559 802
bos@559 803 </sect2>
bos@559 804 <sect2>
bos@559 805 <title>Using compression with ssh</title>
bos@559 806
bos@559 807 <para>Mercurial does not compress data when it uses the ssh
bos@559 808 protocol, because the ssh protocol can transparently compress
bos@559 809 data. However, the default behaviour of ssh clients is
bos@559 810 <emphasis>not</emphasis> to request compression.</para>
bos@559 811
bos@559 812 <para>Over any network other than a fast LAN (even a wireless
bos@559 813 network), using compression is likely to significantly speed
bos@559 814 up Mercurial's network operations. For example, over a WAN,
bos@559 815 someone measured compression as reducing the amount of time
bos@559 816 required to clone a particularly large repository from 51
bos@559 817 minutes to 17 minutes.</para>
bos@559 818
bos@559 819 <para>Both <command>ssh</command> and <command>plink</command>
bos@559 820 accept a <option role="cmd-opt-ssh">-C</option> option which
bos@559 821 turns on compression. You can easily edit your <filename
bos@559 822 role="special"> /.hgrc</filename>\ to enable compression for
bos@559 823 all of Mercurial's uses of the ssh protocol.</para>
bos@559 824 <programlisting>[ui] ssh = ssh -C</programlisting>
bos@559 825
bos@559 826 <para>If you use <command>ssh</command>, you can configure it to
bos@559 827 always use compression when talking to your server. To do
bos@559 828 this, edit your <filename
bos@559 829 role="special">.ssh/config</filename> file (which may not
bos@559 830 yet exist), as follows.</para>
bos@559 831 <programlisting>Host hg Compression yes HostName
bos@559 832 hg.example.com</programlisting>
bos@559 833 <para>This defines an alias, <literal>hg</literal>. When you
bos@559 834 use it on the <command>ssh</command> command line or in a
bos@559 835 Mercurial <literal>ssh</literal>-protocol URL, it will cause
bos@559 836 <command>ssh</command> to connect to
bos@559 837 <literal>hg.example.com</literal> and use compression. This
bos@559 838 gives you both a shorter name to type and compression, each of
bos@559 839 which is a good thing in its own right.</para>
bos@559 840
bos@559 841 </sect2>
bos@559 842 </sect1>
bos@559 843 <sect1 id="sec:collab:cgi">
bos@559 844 <title>Serving over HTTP using CGI</title>
bos@559 845
bos@559 846 <para>Depending on how ambitious you are, configuring Mercurial's
bos@559 847 CGI interface can take anything from a few moments to several
bos@559 848 hours.</para>
bos@559 849
bos@559 850 <para>We'll begin with the simplest of examples, and work our way
bos@559 851 towards a more complex configuration. Even for the most basic
bos@559 852 case, you're almost certainly going to need to read and modify
bos@559 853 your web server's configuration.</para>
bos@559 854
bos@559 855 <note>
bos@559 856 <para> Configuring a web server is a complex, fiddly, and
bos@559 857 highly system-dependent activity. I can't possibly give you
bos@559 858 instructions that will cover anything like all of the cases
bos@559 859 you will encounter. Please use your discretion and judgment in
bos@559 860 following the sections below. Be prepared to make plenty of
bos@559 861 mistakes, and to spend a lot of time reading your server's
bos@559 862 error logs.</para>
bos@559 863 </note>
bos@559 864
bos@559 865 <sect2>
bos@559 866 <title>Web server configuration checklist</title>
bos@559 867
bos@559 868 <para>Before you continue, do take a few moments to check a few
bos@559 869 aspects of your system's setup.</para>
bos@559 870
bos@559 871 <orderedlist>
bos@559 872 <listitem><para>Do you have a web server installed at all?
bos@559 873 Mac OS X ships with Apache, but many other systems may not
bos@559 874 have a web server installed.</para>
bos@559 875 </listitem>
bos@559 876 <listitem><para>If you have a web server installed, is it
bos@559 877 actually running? On most systems, even if one is
bos@559 878 present, it will be disabled by default.</para>
bos@559 879 </listitem>
bos@559 880 <listitem><para>Is your server configured to allow you to run
bos@559 881 CGI programs in the directory where you plan to do so?
bos@559 882 Most servers default to explicitly disabling the ability
bos@559 883 to run CGI programs.</para>
bos@559 884 </listitem></orderedlist>
bos@559 885
bos@559 886 <para>If you don't have a web server installed, and don't have
bos@559 887 substantial experience configuring Apache, you should consider
bos@559 888 using the <literal>lighttpd</literal> web server instead of
bos@559 889 Apache. Apache has a well-deserved reputation for baroque and
bos@559 890 confusing configuration. While <literal>lighttpd</literal> is
bos@559 891 less capable in some ways than Apache, most of these
bos@559 892 capabilities are not relevant to serving Mercurial
bos@559 893 repositories. And <literal>lighttpd</literal> is undeniably
bos@559 894 <emphasis>much</emphasis> easier to get started with than
bos@559 895 Apache.</para>
bos@559 896
bos@559 897 </sect2>
bos@559 898 <sect2>
bos@559 899 <title>Basic CGI configuration</title>
bos@559 900
bos@559 901 <para>On Unix-like systems, it's common for users to have a
bos@559 902 subdirectory named something like <filename
bos@559 903 class="directory">public_html</filename> in their home
bos@559 904 directory, from which they can serve up web pages. A file
bos@559 905 named <filename>foo</filename> in this directory will be
bos@559 906 accessible at a URL of the form
bos@559 907 <literal>http://www.example.com/\
bos@559 908 {</literal>username/foo}.</para>
bos@559 909
bos@559 910 <para>To get started, find the <filename
bos@559 911 role="special">hgweb.cgi</filename> script that should be
bos@559 912 present in your Mercurial installation. If you can't quickly
bos@559 913 find a local copy on your system, simply download one from the
bos@559 914 master Mercurial repository at <ulink
bos@559 915 url="http://www.selenic.com/repo/hg/raw-file/tip/hgweb.cgi">http://www.selenic.com/repo/hg/raw-file/tip/hgweb.cgi</ulink>.</para>
bos@559 916
bos@559 917 <para>You'll need to copy this script into your <filename
bos@559 918 class="directory">public_html</filename> directory, and
bos@559 919 ensure that it's executable.</para>
bos@559 920 <programlisting>cp .../hgweb.cgi ~/public_html chmod 755
bos@559 921 ~/public_html/hgweb.cgi</programlisting>
bos@559 922 <para>The <literal>755</literal> argument to
bos@559 923 <command>chmod</command> is a little more general than just
bos@559 924 making the script executable: it ensures that the script is
bos@559 925 executable by anyone, and that <quote>group</quote> and
bos@559 926 <quote>other</quote> write permissions are
bos@559 927 <emphasis>not</emphasis> set. If you were to leave those
bos@559 928 write permissions enabled, Apache's <literal>suexec</literal>
bos@559 929 subsystem would likely refuse to execute the script. In fact,
bos@559 930 <literal>suexec</literal> also insists that the
bos@559 931 <emphasis>directory</emphasis> in which the script resides
bos@559 932 must not be writable by others.</para>
bos@559 933 <programlisting>chmod 755 ~/public_html</programlisting>
bos@559 934
bos@559 935 <sect3 id="sec:collab:wtf">
bos@559 936 <title>What could <emphasis>possibly</emphasis> go
bos@559 937 wrong?</title>
bos@559 938
bos@559 939 <para>Once you've copied the CGI script into place, go into a
bos@559 940 web browser, and try to open the URL <ulink
bos@559 941 url="http://myhostname/
bos@559 942 myuser/hgweb.cgi">http://myhostname/
bos@559 943 myuser/hgweb.cgi</ulink>, <emphasis>but</emphasis> brace
bos@559 944 yourself for instant failure. There's a high probability
bos@559 945 that trying to visit this URL will fail, and there are many
bos@559 946 possible reasons for this. In fact, you're likely to
bos@559 947 stumble over almost every one of the possible errors below,
bos@559 948 so please read carefully. The following are all of the
bos@559 949 problems I ran into on a system running Fedora 7, with a
bos@559 950 fresh installation of Apache, and a user account that I
bos@559 951 created specially to perform this exercise.</para>
bos@559 952
bos@559 953 <para>Your web server may have per-user directories disabled.
bos@559 954 If you're using Apache, search your config file for a
bos@559 955 <literal>UserDir</literal> directive. If there's none
bos@559 956 present, per-user directories will be disabled. If one
bos@559 957 exists, but its value is <literal>disabled</literal>, then
bos@559 958 per-user directories will be disabled. Otherwise, the
bos@559 959 string after <literal>UserDir</literal> gives the name of
bos@559 960 the subdirectory that Apache will look in under your home
bos@559 961 directory, for example <filename
bos@559 962 class="directory">public_html</filename>.</para>
bos@559 963
bos@559 964 <para>Your file access permissions may be too restrictive.
bos@559 965 The web server must be able to traverse your home directory
bos@559 966 and directories under your <filename
bos@559 967 class="directory">public_html</filename> directory, and
bos@559 968 read files under the latter too. Here's a quick recipe to
bos@559 969 help you to make your permissions more appropriate.</para>
bos@559 970 <programlisting>chmod 755 ~ find ~/public_html -type d -print0
bos@559 971 | xargs -0r chmod 755 find ~/public_html -type f -print0 |
bos@559 972 xargs -0r chmod 644</programlisting>
bos@559 973
bos@559 974 <para>The other possibility with permissions is that you might
bos@559 975 get a completely empty window when you try to load the
bos@559 976 script. In this case, it's likely that your access
ori@561 977 permissions are <emphasis>too permissive</emphasis>. Apache's
bos@559 978 <literal>suexec</literal> subsystem won't execute a script
bos@559 979 that's group- or world-writable, for example.</para>
bos@559 980
bos@559 981 <para>Your web server may be configured to disallow execution
bos@559 982 of CGI programs in your per-user web directory. Here's
bos@559 983 Apache's default per-user configuration from my Fedora
bos@559 984 system.</para>
bos@559 985 <programlisting>&lt;Directory /home/*/public_html&gt;
bos@559 986 AllowOverride FileInfo AuthConfig Limit Options MultiViews
bos@559 987 Indexes SymLinksIfOwnerMatch IncludesNoExec &lt;Limit GET
bos@559 988 POST OPTIONS&gt; Order allow,deny Allow from all
bos@559 989 &lt;/Limit&gt; &lt;LimitExcept GET POST OPTIONS&gt; Order
bos@559 990 deny,allow Deny from all &lt;/LimitExcept&gt;
bos@559 991 &lt;/Directory&gt;</programlisting>
bos@559 992 <para>If you find a similar-looking
bos@559 993 <literal>Directory</literal> group in your Apache
bos@559 994 configuration, the directive to look at inside it is
bos@559 995 <literal>Options</literal>. Add <literal>ExecCGI</literal>
bos@559 996 to the end of this list if it's missing, and restart the web
bos@559 997 server.</para>
bos@559 998
bos@559 999 <para>If you find that Apache serves you the text of the CGI
bos@559 1000 script instead of executing it, you may need to either
bos@559 1001 uncomment (if already present) or add a directive like
bos@559 1002 this.</para>
bos@559 1003 <programlisting>AddHandler cgi-script .cgi</programlisting>
bos@559 1004
bos@559 1005 <para>The next possibility is that you might be served with a
bos@559 1006 colourful Python backtrace claiming that it can't import a
bos@559 1007 <literal>mercurial</literal>-related module. This is
bos@559 1008 actually progress! The server is now capable of executing
bos@559 1009 your CGI script. This error is only likely to occur if
bos@559 1010 you're running a private installation of Mercurial, instead
bos@559 1011 of a system-wide version. Remember that the web server runs
bos@559 1012 the CGI program without any of the environment variables
bos@559 1013 that you take for granted in an interactive session. If
bos@559 1014 this error happens to you, edit your copy of <filename
bos@559 1015 role="special">hgweb.cgi</filename> and follow the
bos@559 1016 directions inside it to correctly set your
bos@559 1017 <envar>PYTHONPATH</envar> environment variable.</para>
bos@559 1018
bos@559 1019 <para>Finally, you are <emphasis>certain</emphasis> to by
bos@559 1020 served with another colourful Python backtrace: this one
bos@559 1021 will complain that it can't find <filename
bos@559 1022 class="directory">/path/to/repository</filename>. Edit
bos@559 1023 your <filename role="special">hgweb.cgi</filename> script
bos@559 1024 and replace the <filename
bos@559 1025 class="directory">/path/to/repository</filename> string
bos@559 1026 with the complete path to the repository you want to serve
bos@559 1027 up.</para>
bos@559 1028
bos@559 1029 <para>At this point, when you try to reload the page, you
bos@559 1030 should be presented with a nice HTML view of your
bos@559 1031 repository's history. Whew!</para>
bos@559 1032
bos@559 1033 </sect3>
bos@559 1034 <sect3>
bos@559 1035 <title>Configuring lighttpd</title>
bos@559 1036
bos@559 1037 <para>To be exhaustive in my experiments, I tried configuring
bos@559 1038 the increasingly popular <literal>lighttpd</literal> web
bos@559 1039 server to serve the same repository as I described with
bos@559 1040 Apache above. I had already overcome all of the problems I
bos@559 1041 outlined with Apache, many of which are not server-specific.
bos@559 1042 As a result, I was fairly sure that my file and directory
bos@559 1043 permissions were good, and that my <filename
bos@559 1044 role="special">hgweb.cgi</filename> script was properly
bos@559 1045 edited.</para>
bos@559 1046
bos@559 1047 <para>Once I had Apache running, getting
bos@559 1048 <literal>lighttpd</literal> to serve the repository was a
bos@559 1049 snap (in other words, even if you're trying to use
bos@559 1050 <literal>lighttpd</literal>, you should read the Apache
bos@559 1051 section). I first had to edit the
bos@559 1052 <literal>mod_access</literal> section of its config file to
bos@559 1053 enable <literal>mod_cgi</literal> and
bos@559 1054 <literal>mod_userdir</literal>, both of which were disabled
bos@559 1055 by default on my system. I then added a few lines to the
bos@559 1056 end of the config file, to configure these modules.</para>
bos@559 1057 <programlisting>userdir.path = "public_html" cgi.assign = (
bos@559 1058 ".cgi" =&gt; "" )</programlisting>
bos@559 1059 <para>With this done, <literal>lighttpd</literal> ran
bos@559 1060 immediately for me. If I had configured
bos@559 1061 <literal>lighttpd</literal> before Apache, I'd almost
bos@559 1062 certainly have run into many of the same system-level
bos@559 1063 configuration problems as I did with Apache. However, I
bos@559 1064 found <literal>lighttpd</literal> to be noticeably easier to
bos@559 1065 configure than Apache, even though I've used Apache for over
bos@559 1066 a decade, and this was my first exposure to
bos@559 1067 <literal>lighttpd</literal>.</para>
bos@559 1068
bos@559 1069 </sect3>
bos@559 1070 </sect2>
bos@559 1071 <sect2>
bos@559 1072 <title>Sharing multiple repositories with one CGI script</title>
bos@559 1073
bos@559 1074 <para>The <filename role="special">hgweb.cgi</filename> script
bos@559 1075 only lets you publish a single repository, which is an
bos@559 1076 annoying restriction. If you want to publish more than one
bos@559 1077 without wracking yourself with multiple copies of the same
bos@559 1078 script, each with different names, a better choice is to use
bos@559 1079 the <filename role="special">hgwebdir.cgi</filename>
bos@559 1080 script.</para>
bos@559 1081
bos@559 1082 <para>The procedure to configure <filename
bos@559 1083 role="special">hgwebdir.cgi</filename> is only a little more
bos@559 1084 involved than for <filename
bos@559 1085 role="special">hgweb.cgi</filename>. First, you must obtain
bos@559 1086 a copy of the script. If you don't have one handy, you can
bos@559 1087 download a copy from the master Mercurial repository at <ulink
bos@559 1088 url="http://www.selenic.com/repo/hg/raw-file/tip/hgwebdir.cgi">http://www.selenic.com/repo/hg/raw-file/tip/hgwebdir.cgi</ulink>.</para>
bos@559 1089
bos@559 1090 <para>You'll need to copy this script into your <filename
bos@559 1091 class="directory">public_html</filename> directory, and
bos@559 1092 ensure that it's executable.</para>
bos@559 1093 <programlisting>cp .../hgwebdir.cgi ~/public_html chmod 755
bos@559 1094 ~/public_html ~/public_html/hgwebdir.cgi</programlisting>
bos@559 1095 <para>With basic configuration out of the way, try to visit
bos@559 1096 <ulink url="http://myhostname/
bos@559 1097 myuser/hgwebdir.cgi">http://myhostname/
bos@559 1098 myuser/hgwebdir.cgi</ulink> in your browser. It should
bos@559 1099 display an empty list of repositories. If you get a blank
bos@559 1100 window or error message, try walking through the list of
bos@559 1101 potential problems in section <xref
bos@559 1102 linkend="sec:collab:wtf"/>.</para>
bos@559 1103
bos@559 1104 <para>The <filename role="special">hgwebdir.cgi</filename>
bos@559 1105 script relies on an external configuration file. By default,
bos@559 1106 it searches for a file named <filename
bos@559 1107 role="special">hgweb.config</filename> in the same directory
bos@559 1108 as itself. You'll need to create this file, and make it
bos@559 1109 world-readable. The format of the file is similar to a
bos@559 1110 Windows <quote>ini</quote> file, as understood by Python's
bos@559 1111 <literal>ConfigParser</literal>
bos@559 1112 <citation>web:configparser</citation> module.</para>
bos@559 1113
bos@559 1114 <para>The easiest way to configure <filename
bos@559 1115 role="special">hgwebdir.cgi</filename> is with a section
bos@559 1116 named <literal>collections</literal>. This will automatically
bos@559 1117 publish <emphasis>every</emphasis> repository under the
bos@559 1118 directories you name. The section should look like
bos@559 1119 this:</para>
bos@559 1120 <programlisting>[collections] /my/root =
bos@559 1121 /my/root</programlisting>
bos@559 1122 <para>Mercurial interprets this by looking at the directory name
bos@559 1123 on the <emphasis>right</emphasis> hand side of the
bos@559 1124 <quote><literal>=</literal></quote> sign; finding repositories
bos@559 1125 in that directory hierarchy; and using the text on the
bos@559 1126 <emphasis>left</emphasis> to strip off matching text from the
bos@559 1127 names it will actually list in the web interface. The
bos@559 1128 remaining component of a path after this stripping has
bos@559 1129 occurred is called a <quote>virtual path</quote>.</para>
bos@559 1130
bos@559 1131 <para>Given the example above, if we have a repository whose
bos@559 1132 local path is <filename
bos@559 1133 class="directory">/my/root/this/repo</filename>, the CGI
bos@559 1134 script will strip the leading <filename
bos@559 1135 class="directory">/my/root</filename> from the name, and
bos@559 1136 publish the repository with a virtual path of <filename
bos@559 1137 class="directory">this/repo</filename>. If the base URL for
bos@559 1138 our CGI script is <ulink url="http://myhostname/
bos@559 1139 myuser/hgwebdir.cgi">http://myhostname/
bos@559 1140 myuser/hgwebdir.cgi</ulink>, the complete URL for that
bos@559 1141 repository will be <ulink url="http://myhostname/
bos@559 1142 myuser/hgwebdir.cgi/this/repo">http://myhostname/
bos@559 1143 myuser/hgwebdir.cgi/this/repo</ulink>.</para>
bos@559 1144
bos@559 1145 <para>If we replace <filename
bos@559 1146 class="directory">/my/root</filename> on the left hand side
bos@559 1147 of this example with <filename
bos@559 1148 class="directory">/my</filename>, then <filename
bos@559 1149 role="special">hgwebdir.cgi</filename> will only strip off
bos@559 1150 <filename class="directory">/my</filename> from the repository
bos@559 1151 name, and will give us a virtual path of <filename
bos@559 1152 class="directory">root/this/repo</filename> instead of
bos@559 1153 <filename class="directory">this/repo</filename>.</para>
bos@559 1154
bos@559 1155 <para>The <filename role="special">hgwebdir.cgi</filename>
bos@559 1156 script will recursively search each directory listed in the
bos@559 1157 <literal>collections</literal> section of its configuration
bos@559 1158 file, but it will <literal>not</literal> recurse into the
bos@559 1159 repositories it finds.</para>
bos@559 1160
bos@559 1161 <para>The <literal>collections</literal> mechanism makes it easy
bos@559 1162 to publish many repositories in a <quote>fire and
bos@559 1163 forget</quote> manner. You only need to set up the CGI
bos@559 1164 script and configuration file one time. Afterwards, you can
bos@559 1165 publish or unpublish a repository at any time by simply moving
bos@559 1166 it into, or out of, the directory hierarchy in which you've
bos@559 1167 configured <filename role="special">hgwebdir.cgi</filename> to
bos@559 1168 look.</para>
bos@559 1169
bos@559 1170 <sect3>
bos@559 1171 <title>Explicitly specifying which repositories to
bos@559 1172 publish</title>
bos@559 1173
bos@559 1174 <para>In addition to the <literal>collections</literal>
bos@559 1175 mechanism, the <filename
bos@559 1176 role="special">hgwebdir.cgi</filename> script allows you
bos@559 1177 to publish a specific list of repositories. To do so,
bos@559 1178 create a <literal>paths</literal> section, with contents of
bos@559 1179 the following form.</para>
bos@559 1180 <programlisting>[paths] repo1 = /my/path/to/some/repo repo2 =
bos@559 1181 /some/path/to/another</programlisting>
bos@559 1182 <para>In this case, the virtual path (the component that will
bos@559 1183 appear in a URL) is on the left hand side of each
bos@559 1184 definition, while the path to the repository is on the
bos@559 1185 right. Notice that there does not need to be any
bos@559 1186 relationship between the virtual path you choose and the
bos@559 1187 location of a repository in your filesystem.</para>
bos@559 1188
bos@559 1189 <para>If you wish, you can use both the
bos@559 1190 <literal>collections</literal> and <literal>paths</literal>
bos@559 1191 mechanisms simultaneously in a single configuration
bos@559 1192 file.</para>
bos@559 1193
bos@559 1194 <note>
bos@559 1195 <para> If multiple repositories have the same virtual path,
bos@559 1196 <filename role="special">hgwebdir.cgi</filename> will not
bos@559 1197 report an error. Instead, it will behave
bos@559 1198 unpredictably.</para>
bos@559 1199 </note>
bos@559 1200
bos@559 1201 </sect3>
bos@559 1202 </sect2>
bos@559 1203 <sect2>
bos@559 1204 <title>Downloading source archives</title>
bos@559 1205
bos@559 1206 <para>Mercurial's web interface lets users download an archive
bos@559 1207 of any revision. This archive will contain a snapshot of the
bos@559 1208 working directory as of that revision, but it will not contain
bos@559 1209 a copy of the repository data.</para>
bos@559 1210
bos@559 1211 <para>By default, this feature is not enabled. To enable it,
bos@559 1212 you'll need to add an <envar
bos@559 1213 role="rc-item-web">allow_archive</envar> item to the
bos@559 1214 <literal role="rc-web">web</literal> section of your <filename
bos@559 1215 role="special"> /.hgrc</filename>.</para>
bos@559 1216
bos@559 1217 </sect2>
bos@559 1218 <sect2>
bos@559 1219 <title>Web configuration options</title>
bos@559 1220
bos@559 1221 <para>Mercurial's web interfaces (the <command role="hg-cmd">hg
bos@559 1222 serve</command> command, and the <filename
bos@559 1223 role="special">hgweb.cgi</filename> and <filename
bos@559 1224 role="special">hgwebdir.cgi</filename> scripts) have a
bos@559 1225 number of configuration options that you can set. These
bos@559 1226 belong in a section named <literal
bos@559 1227 role="rc-web">web</literal>.</para>
bos@559 1228 <itemizedlist>
bos@559 1229 <listitem><para><envar
bos@559 1230 role="rc-item-web">allow_archive</envar>: Determines
bos@559 1231 which (if any) archive download mechanisms Mercurial
bos@559 1232 supports. If you enable this feature, users of the web
bos@559 1233 interface will be able to download an archive of whatever
bos@559 1234 revision of a repository they are viewing. To enable the
bos@559 1235 archive feature, this item must take the form of a
bos@559 1236 sequence of words drawn from the list below.</para>
bos@559 1237 <itemizedlist>
bos@559 1238 <listitem><para><literal>bz2</literal>: A
bos@559 1239 <command>tar</command> archive, compressed using
bos@559 1240 <literal>bzip2</literal> compression. This has the
bos@559 1241 best compression ratio, but uses the most CPU time on
bos@559 1242 the server.</para>
bos@559 1243 </listitem>
bos@559 1244 <listitem><para><literal>gz</literal>: A
bos@559 1245 <command>tar</command> archive, compressed using
bos@559 1246 <literal>gzip</literal> compression.</para>
bos@559 1247 </listitem>
bos@559 1248 <listitem><para><literal>zip</literal>: A
bos@559 1249 <command>zip</command> archive, compressed using LZW
bos@559 1250 compression. This format has the worst compression
bos@559 1251 ratio, but is widely used in the Windows world.</para>
bos@559 1252 </listitem>
bos@559 1253 </itemizedlist>
bos@559 1254 <para> If you provide an empty list, or don't have an
bos@559 1255 <envar role="rc-item-web">allow_archive</envar> entry at
bos@559 1256 all, this feature will be disabled. Here is an example of
bos@559 1257 how to enable all three supported formats.</para>
bos@559 1258 <programlisting>[web] allow_archive = bz2 gz
bos@559 1259 zip</programlisting>
bos@559 1260 </listitem>
bos@559 1261 <listitem><para><envar role="rc-item-web">allowpull</envar>:
bos@559 1262 Boolean. Determines whether the web interface allows
bos@559 1263 remote users to <command role="hg-cmd">hg pull</command>
bos@559 1264 and <command role="hg-cmd">hg clone</command> this
bos@559 1265 repository over HTTP. If set to <literal>no</literal> or
bos@559 1266 <literal>false</literal>, only the
bos@559 1267 <quote>human-oriented</quote> portion of the web interface
bos@559 1268 is available.</para>
bos@559 1269 </listitem>
bos@559 1270 <listitem><para><envar role="rc-item-web">contact</envar>:
bos@559 1271 String. A free-form (but preferably brief) string
bos@559 1272 identifying the person or group in charge of the
bos@559 1273 repository. This often contains the name and email
bos@559 1274 address of a person or mailing list. It often makes sense
bos@559 1275 to place this entry in a repository's own <filename
bos@559 1276 role="special">.hg/hgrc</filename> file, but it can make
bos@559 1277 sense to use in a global <filename role="special">
bos@559 1278 /.hgrc</filename>\ if every repository has a single
bos@559 1279 maintainer.</para>
bos@559 1280 </listitem>
bos@559 1281 <listitem><para><envar role="rc-item-web">maxchanges</envar>:
bos@559 1282 Integer. The default maximum number of changesets to
bos@559 1283 display in a single page of output.</para>
bos@559 1284 </listitem>
bos@559 1285 <listitem><para><envar role="rc-item-web">maxfiles</envar>:
bos@559 1286 Integer. The default maximum number of modified files to
bos@559 1287 display in a single page of output.</para>
bos@559 1288 </listitem>
bos@559 1289 <listitem><para><envar role="rc-item-web">stripes</envar>:
bos@559 1290 Integer. If the web interface displays alternating
bos@559 1291 <quote>stripes</quote> to make it easier to visually align
bos@559 1292 rows when you are looking at a table, this number controls
bos@559 1293 the number of rows in each stripe.</para>
bos@559 1294 </listitem>
bos@559 1295 <listitem><para><envar role="rc-item-web">style</envar>:
bos@559 1296 Controls the template Mercurial uses to display the web
bos@559 1297 interface. Mercurial ships with two web templates, named
bos@559 1298 <literal>default</literal> and <literal>gitweb</literal>
bos@559 1299 (the latter is much more visually attractive). You can
bos@559 1300 also specify a custom template of your own; see chapter
bos@559 1301 <xref linkend="chap:template"/> for details.
bos@559 1302 Here, you can see how to enable the
bos@559 1303 <literal>gitweb</literal> style.</para>
bos@559 1304 <programlisting>[web] style = gitweb</programlisting>
bos@559 1305 </listitem>
bos@559 1306 <listitem><para><envar role="rc-item-web">templates</envar>:
bos@559 1307 Path. The directory in which to search for template
bos@559 1308 files. By default, Mercurial searches in the directory in
bos@559 1309 which it was installed.</para>
bos@559 1310 </listitem></itemizedlist>
bos@559 1311 <para>If you are using <filename
bos@559 1312 role="special">hgwebdir.cgi</filename>, you can place a few
bos@559 1313 configuration items in a <literal role="rc-web">web</literal>
bos@559 1314 section of the <filename
bos@559 1315 role="special">hgweb.config</filename> file instead of a
bos@559 1316 <filename role="special"> /.hgrc</filename>\ file, for
bos@559 1317 convenience. These items are <envar
bos@559 1318 role="rc-item-web">motd</envar> and <envar
bos@559 1319 role="rc-item-web">style</envar>.</para>
bos@559 1320
bos@559 1321 <sect3>
bos@559 1322 <title>Options specific to an individual repository</title>
bos@559 1323
bos@559 1324 <para>A few <literal role="rc-web">web</literal> configuration
bos@559 1325 items ought to be placed in a repository's local <filename
bos@559 1326 role="special">.hg/hgrc</filename>, rather than a user's
bos@559 1327 or global <filename role="special">
bos@559 1328 /.hgrc</filename>.</para>
bos@559 1329 <itemizedlist>
bos@559 1330 <listitem><para><envar
bos@559 1331 role="rc-item-web">description</envar>: String. A
bos@559 1332 free-form (but preferably brief) string that describes
bos@559 1333 the contents or purpose of the repository.</para>
bos@559 1334 </listitem>
bos@559 1335 <listitem><para><envar role="rc-item-web">name</envar>:
bos@559 1336 String. The name to use for the repository in the web
bos@559 1337 interface. This overrides the default name, which is
bos@559 1338 the last component of the repository's path.</para>
bos@559 1339 </listitem></itemizedlist>
bos@559 1340
bos@559 1341 </sect3>
bos@559 1342 <sect3>
bos@559 1343 <title>Options specific to the <command role="hg-cmd">hg
bos@559 1344 serve</command> command</title>
bos@559 1345
bos@559 1346 <para>Some of the items in the <literal
bos@559 1347 role="rc-web">web</literal> section of a <filename
bos@559 1348 role="special"> /.hgrc</filename>\ file are only for use
bos@559 1349 with the <command role="hg-cmd">hg serve</command>
bos@559 1350 command.</para>
bos@559 1351 <itemizedlist>
bos@559 1352 <listitem><para><envar role="rc-item-web">accesslog</envar>:
bos@559 1353 Path. The name of a file into which to write an access
bos@559 1354 log. By default, the <command role="hg-cmd">hg
bos@559 1355 serve</command> command writes this information to
bos@559 1356 standard output, not to a file. Log entries are written
bos@559 1357 in the standard <quote>combined</quote> file format used
bos@559 1358 by almost all web servers.</para>
bos@559 1359 </listitem>
bos@559 1360 <listitem><para><envar role="rc-item-web">address</envar>:
bos@559 1361 String. The local address on which the server should
bos@559 1362 listen for incoming connections. By default, the server
bos@559 1363 listens on all addresses.</para>
bos@559 1364 </listitem>
bos@559 1365 <listitem><para><envar role="rc-item-web">errorlog</envar>:
bos@559 1366 Path. The name of a file into which to write an error
bos@559 1367 log. By default, the <command role="hg-cmd">hg
bos@559 1368 serve</command> command writes this information to
bos@559 1369 standard error, not to a file.</para>
bos@559 1370 </listitem>
bos@559 1371 <listitem><para><envar role="rc-item-web">ipv6</envar>:
bos@559 1372 Boolean. Whether to use the IPv6 protocol. By default,
bos@559 1373 IPv6 is not used.</para>
bos@559 1374 </listitem>
bos@559 1375 <listitem><para><envar role="rc-item-web">port</envar>:
bos@559 1376 Integer. The TCP port number on which the server should
bos@559 1377 listen. The default port number used is 8000.</para>
bos@559 1378 </listitem></itemizedlist>
bos@559 1379
bos@559 1380 </sect3>
bos@559 1381 <sect3>
bos@559 1382 <title>Choosing the right <filename role="special">
bos@559 1383 /.hgrc</filename>\ file to add <literal
bos@559 1384 role="rc-web">web</literal> items to</title>
bos@559 1385
bos@559 1386 <para>It is important to remember that a web server like
bos@559 1387 Apache or <literal>lighttpd</literal> will run under a user
bos@559 1388 ID that is different to yours. CGI scripts run by your
bos@559 1389 server, such as <filename
bos@559 1390 role="special">hgweb.cgi</filename>, will usually also run
bos@559 1391 under that user ID.</para>
bos@559 1392
bos@559 1393 <para>If you add <literal role="rc-web">web</literal> items to
bos@559 1394 your own personal <filename role="special">
bos@559 1395 /.hgrc</filename>\ file, CGI scripts won't read that
bos@559 1396 <filename role="special"> /.hgrc</filename>\ file. Those
bos@559 1397 settings will thus only affect the behaviour of the <command
bos@559 1398 role="hg-cmd">hg serve</command> command when you run it.
bos@559 1399 To cause CGI scripts to see your settings, either create a
bos@559 1400 <filename role="special"> /.hgrc</filename>\ file in the
bos@559 1401 home directory of the user ID that runs your web server, or
bos@559 1402 add those settings to a system-wide <filename
bos@559 1403 role="special"> /.hgrc</filename>\ file.</para>
bos@559 1404
bos@559 1405
bos@559 1406 </sect3>
bos@559 1407 </sect2>
bos@559 1408 </sect1>
bos@559 1409 </chapter>
bos@559 1410
bos@559 1411 <!--
bos@559 1412 local variables:
bos@559 1413 sgml-parent-document: ("00book.xml" "book" "chapter")
bos@559 1414 end:
bos@559 1415 -->