Mercurial_ The Definitive Guide - Bryan O'Sullivan [43]
To people who come from more orderly project backgrounds, the comparatively chaotic Linux kernel development process often seems completely insane. It’s subject to the whims of individuals; people make sweeping changes whenever they deem it appropriate; and the pace of development is astounding. And yet Linux is a highly successful, well-regarded piece of software.
Pull-Only Versus Shared-Push Collaboration
A perpetual source of heat in the open source community is whether a development model in which people only ever pull changes from others is “better than” one in which multiple people can push changes to a shared repository.
Typically, the backers of the shared-push model use tools that actively enforce this approach. If you’re using a centralized revision control tool such as Subversion, there’s no way to make a choice over which model you’ll use: the tool gives you shared-push, and if you want to do anything else, you’ll have to roll your own approach on top (such as applying a patch by hand).
A good distributed revision control tool will support both models. You and your collaborators can then structure how you work together based on your own needs and preferences, not on what contortions your tools force you into.
Where Collaboration Meets Branch Management
Once you and your team set up some shared repositories and start propagating changes back and forth between local and shared repos, you begin to face a related but slightly different challenge: that of managing the multiple directions in which your team may be moving at once. Even though this subject is intimately related to how your team collaborates, it’s dense enough to merit treatment of its own, in Chapter 8.
The Technical Side of Sharing
The remainder of this chapter is devoted to the question of sharing changes with your collaborators.
Informal Sharing with hg serve
Mercurial’s hg serve command is wonderfully suited to small, tight-knit, and fast-paced group environments. It also provides a great way to get a feel for using Mercurial commands over a network.
Run hg serve inside a repository, and in under a second it will bring up a specialized HTTP server; this will accept connections from any client, and serve up data for that repository until you terminate it. Anyone who knows the URL of the server you just started, and can talk to your computer over the network, can then use a web browser or Mercurial to read data from that repository. A URL for a hg serve instance running on a laptop is likely to look something like http://my-laptop.local:8000/.
The hg serve command is not a general-purpose web server. It can do only two things:
Allow people to browse the history of the repository it’s serving, from their normal web browsers.
Speak Mercurial’s wire protocol, so that people can hg clone or hg pull changes from that repository.
In particular, hg serve won’t allow remote users to modify your repository. It’s intended for read-only use.
If you’re getting started with Mercurial, there’s nothing to prevent you from using hg serve to serve up a repository on your own computer, then use commands like hg clone, hg incoming, and so on to talk to that server as if the repository were hosted remotely. This can help you to quickly get acquainted with using commands on network-hosted repositories.
A Few Things to Keep in Mind
Because it provides unauthenticated read access to all clients, you should only use hg serve in an environment where you either don’t care, or have complete control over, who can access your network and pull data from your repository.
The hg serve command knows nothing about any firewall software you might have installed on your system or network. It cannot detect or control your firewall software. If other people are unable to talk to a running hg serve instance, the second thing you should do (after you make sure that they’re using the correct