• Choose a category
• All
• Classic-Fiction

The syntaxes for the acl.allow and acl.deny sections are identical. On the left of each entry is a glob pattern that matches files or directories, relative to the root of the repository; on the right, a username.

In the following example, the user docwriter can only push changes to the docs subtree of the repository, while intern can push changes to any file or directory except source/sensitive.

[acl.allow]

docs/** = docwriter

[acl.deny]

source/sensitive/** = intern

Testing and troubleshooting

If you want to test the acl hook, run it with Mercurial’s debugging output enabled. Since you’ll probably be running it on a server where it’s not convenient (or sometimes impossible) to pass in the --debug option, don’t forget that you can enable debugging output in your ~/.hgrc:

[ui]

debug = true

With this enabled, the acl hook will print enough information to let you figure out why it is allowing or forbidding pushes from specific users.

bugzilla—Integration with Bugzilla

The bugzilla extension adds a comment to a Bugzilla bug whenever it finds a reference to that bug ID in a commit comment. You can install this hook on a shared server, so that any time a remote user pushes changes to this server, the hook gets run.

The hook adds a comment to the bug that looks like this (you can configure the contents of the comment—see below):

Changeset aad8b264143a, made by Joe User

in the frobnitz repository, refers

to this bug. For complete details, see

http://hg.domain.com/frobnitz?cmd=changeset;node=aad8b264143a

Changeset description: Fix bug 10483 by guarding against some

NULL pointers

The value of this hook is that it automates the process of updating a bug any time a changeset refers to it. If you configure the hook properly, it makes it easy for people to browse straight from a Bugzilla bug to a changeset that refers to that bug.

You can use the code in this hook as a starting point for some more exotic Bugzilla integration recipes. Here are a few possibilities:

Require that every changeset pushed to the server have a valid bug ID in its commit comment. In this case, you’d want to configure the hook as a pretxncommit hook. This would allow the hook to reject changes that didn’t contain bug IDs.

Allow incoming changesets to automatically modify the state of a bug, as well as simply adding a comment. For example, the hook could recognize the string “fixed bug 31337” as indicating that it should update the state of bug 31337 to “requires testing.”

Configuring the bugzilla hook

You should configure this hook in your server’s ~/.hgrc as an incoming hook, for example as follows:

[hooks]

incoming.bugzilla = python:hgext.bugzilla.hook

Because of the specialized nature of this hook, and because Bugzilla was not written with this kind of integration in mind, configuring this hook is a somewhat involved process.

Before you begin, you must install the MySQL bindings for Python on the host(s) where you’ll be running the hook. If this is not available as a binary package for your system, you can download it from http://sourceforge.net/projects/mysql-python.

Configuration information for this hook lives in the bugzilla section of your ~/.hgrc.

version: The version of Bugzilla installed on the server. The database schema that Bugzilla uses changes occasionally, so this hook has to know exactly which schema to use.

host: The hostname of the MySQL server that stores your Bugzilla data. The database must be configured to allow connections from whatever host you are running the bugzilla hook on.

user: The username with which to connect to the MySQL server. The database must be configured to allow this user to connect from whatever host you are running the bugzilla hook on. This user must be able to access and modify Bugzilla tables. The default value of this item is bugs, which is the standard name of the Bugzilla user in a MySQL database.

password: The MySQL password for the user you configured above. This is stored as plain text, so you should make