Mercurial_ The Definitive Guide - Bryan O'Sullivan [51]
description: String. A free-form (but preferably brief) string that describes the contents or purpose of the repository.
name: String. The name to use for the repository in the web interface. This overrides the default name, which is the last component of the repository’s path.
Options specific to the hg serve command
Some of the items in the web section of a ~/.hgrc file are only for use with the hg serve command.
accesslog: Path. The name of a file into which to write an access log. By default, the hg serve command writes this information to standard output, not to a file. Log entries are written in the standard “combined” file format used by almost all web servers.
address: String. The local address on which the server should listen for incoming connections. By default, the server listens on all addresses.
errorlog: Path. The name of a file into which to write an error log. By default, the hg serve command writes this information to standard error, not to a file.
ipv6: Boolean. Whether to use the IPv6 protocol. By default, IPv6 is not used.
port: Integer. The TCP port number on which the server should listen. The default port number used is 8000.
Choosing the right ~/.hgrc file to add web items to
It is important to remember that a web server like Apache or lighttpd will run under a user ID that is different from yours. CGI scripts run by your server, such as hgweb.cgi, will usually also run under that user ID.
If you add web items to your own personal ~/.hgrc file, CGI scripts won’t read that ~/.hgrc file. Those settings will thus only affect the behavior of the hg serve command when you run it. To cause CGI scripts to see your settings, either create a ~/.hgrc file in the home directory of the user ID that runs your web server, or add those settings to a system-wide hgrc file.
System-Wide Configuration
On Unix-like systems shared by multiple users (such as a server to which people publish changes), it often makes sense to set up some global default behaviors, such as what theme to use in web interfaces.
If a file named /etc/mercurial/hgrc exists, Mercurial will read it at startup time and apply any configuration settings it finds in that file. It will also look for files ending in a .rc extension in a directory named /etc/mercurial/hgrc.d, and apply any configuration settings it finds in each of those files.
Making Mercurial More Trusting
One situation in which a global hgrc can be useful is if users are pulling changes owned by other users. By default, Mercurial will not trust most of the configuration items in a .hg/hgrc file inside a repository that is owned by a different user. If we clone or pull changes from such a repository, Mercurial will print a warning stating that it does not trust their .hg/hgrc.
If everyone in a particular Unix group is on the same team and should trust each other’s configuration settings, or we want to trust particular users, we can override Mercurial’s skeptical defaults by creating a system-wide hgrc file such as the following:
# Save this as e.g. /etc/mercurial/hgrc.d/trust.rc
[trusted]
# Trust all entries in any hgrc file owned by the "editors" or
# "www-data" groups.
groups = editors, www-data
# Trust entries in hgrc files owned by the following users.
users = apache, bobo
Chapter 7. Filenames and Pattern Matching
Mercurial provides mechanisms that let you work with file names in a consistent and expressive way.
Simple File Naming
Mercurial uses a unified piece of machinery “under the hood” to handle filenames. Every command behaves uniformly with respect to filenames. The way in which commands work with filenames is as follows.
If you explicitly name real files on the command line, Mercurial works with exactly those files, as you would expect.
$ hg add COPYING README examples/simple.py
When you provide a directory name, Mercurial will interpret this as “operate on every file in this directory