view mercurial/help/hgweb.txt @ 21809:e250b8300e6e

parsers: inline fields of dirstate values in C version Previously, while unpacking the dirstate we'd create 3-4 new CPython objects for most dirstate values: - the state is a single character string, which is pooled by CPython - the mode is a new object if it isn't 0 due to being in the lookup set - the size is a new object if it is greater than 255 - the mtime is a new object if it isn't -1 due to being in the lookup set - the tuple to contain them all In some cases such as regular hg status, we actually look at all the objects. In other cases like hg add, hg status for a subdirectory, or hg status with the third-party hgwatchman enabled, we look at almost none of the objects. This patch eliminates most object creation in these cases by defining a custom C struct that is exposed to Python with an interface similar to a tuple. Only when tuple elements are actually requested are the respective objects created. The gains, where they're expected, are significant. The following tests are run against a working copy with over 270,000 files. parse_dirstate becomes significantly faster: $ hg perfdirstate before: wall 0.186437 comb 0.180000 user 0.160000 sys 0.020000 (best of 35) after: wall 0.093158 comb 0.100000 user 0.090000 sys 0.010000 (best of 95) and as a result, several commands benefit: $ time hg status # with hgwatchman enabled before: 0.42s user 0.14s system 99% cpu 0.563 total after: 0.34s user 0.12s system 99% cpu 0.471 total $ time hg add new-file before: 0.85s user 0.18s system 99% cpu 1.033 total after: 0.76s user 0.17s system 99% cpu 0.931 total There is a slight regression in regular status performance, but this is fixed in an upcoming patch.
author Siddharth Agarwal <sid0@fb.com>
date Tue, 27 May 2014 14:27:41 -0700
parents e7cfe3587ea4
children afe03a616525
line wrap: on
line source

Mercurial's internal web server, hgweb, can serve either a single
repository, or a tree of repositories. In the second case, repository
paths and global options can be defined using a dedicated
configuration file common to :hg:`serve`, ``hgweb.wsgi``,
``hgweb.cgi`` and ``hgweb.fcgi``.

This file uses the same syntax as other Mercurial configuration files
but recognizes only the following sections:

  - web
  - paths
  - collections

The ``web`` options are thoroughly described in :hg:`help config`.

The ``paths`` section maps URL paths to paths of repositories in the
filesystem. hgweb will not expose the filesystem directly - only
Mercurial repositories can be published and only according to the
configuration.

The left hand side is the path in the URL. Note that hgweb reserves
subpaths like ``rev`` or ``file``, try using different names for
nested repositories to avoid confusing effects.

The right hand side is the path in the filesystem. If the specified
path ends with ``*`` or ``**`` the filesystem will be searched
recursively for repositories below that point.
With ``*`` it will not recurse into the repositories it finds (except for
``.hg/patches``).
With ``**`` it will also search inside repository working directories
and possibly find subrepositories.

In this example::

  [paths]
  /projects/a = /srv/tmprepos/a
  /projects/b = c:/repos/b
  / = /srv/repos/*
  /user/bob = /home/bob/repos/**

- The first two entries make two repositories in different directories
  appear under the same directory in the web interface
- The third entry will publish every Mercurial repository found in
  ``/srv/repos/``, for instance the repository ``/srv/repos/quux/``
  will appear as ``http://server/quux/``
- The fourth entry will publish both ``http://server/user/bob/quux/``
  and ``http://server/user/bob/quux/testsubrepo/``

The ``collections`` section is deprecated and has been superseded by
``paths``.