Mercurial_ The Definitive Guide - Bryan O'Sullivan [39]
Also for human consumption, the web interface provides Atom and RSS feeds of the changes in a repository. This lets you “subscribe” to a repository using your favorite feed reader, and be automatically notified of activity in that repository as soon as it happens. I find this capability much more convenient than the model of subscribing to a mailing list to which notifications are sent, as it requires no additional configuration on the part of whoever is serving the repository.
The web interface also lets remote users clone a repository, pull changes from it, and (when the server is configured to permit it) push changes back to it. Mercurial’s HTTP tunneling protocol aggressively compresses data, so that it works efficiently even over low-bandwidth network connections.
The easiest way to get started with the web interface is to use your web browser to visit an existing repository, such as the master Mercurial repository at http://www.selenic.com/repo/hg.
If you’re interested in providing a web interface to your own repositories, there are several good ways to do this.
The easiest and fastest way to get started in an informal environment is to use the hg serve command, which is best suited to short-term “lightweight” serving. See Informal Sharing with hg serve for details of how to use this command.
For longer-lived repositories that you’d like to have permanently available, there are several public hosting services. Some are free to open source projects, while others offer paid commercial hosting. An up-to-date list is available at http://www.selenic.com/mercurial/wiki/index.cgi/MercurialHosting.
If you would prefer to host your own repositories, Mercurial has built-in support for several popular hosting technologies, most notably CGI (Common Gateway Interface) and WSGI (Web Services Gateway Interface). See Serving Over HTTP Using CGI for details of CGI and WSGI configuration.
Collaboration Models
With a suitably flexible tool, making decisions about workflow is much more of a social engineering challenge than a technical one. Mercurial imposes few limitations on how you can structure the flow of work in a project, so it’s up to you and your group to set up and live with a model that matches your own particular needs.
Factors to Keep in Mind
The most important aspect of any model that you must keep in mind is how well it matches the needs and capabilities of the people who will be using it. This might seem self-evident; even so, you can’t afford to forget it even for a moment.
I once put together a workflow model that seemed to make perfect sense to me, but that caused a considerable amount of consternation and strife within my development team. In spite of my attempts to explain why we needed a complex set of branches, and how changes ought to flow between them, a few team members revolted. Even though they were smart people, they didn’t want to pay attention to the constraints we were operating under, or face the consequences of those constraints in the details of the model that I was advocating.
Don’t sweep foreseeable social or technical problems under the rug. Whatever scheme you put into effect, you should plan for mistakes and problem scenarios. Consider adding automated machinery to prevent, or quickly recover from, trouble that you can anticipate. As an example, if you intend to have a branch with not-for-release changes in it, you’d do well to think early about the possibility that someone might accidentally merge those changes into a release branch. You could avoid this particular problem by writing a hook that prevents changes from being merged from an inappropriate branch.
Informal Anarchy
I wouldn’t suggest an “anything goes” approach as something sustainable, but it’s a model that’s easy to grasp, and it works perfectly well in a few unusual situations.
As one example, many projects have a loose-knit group of collaborators who rarely physically meet