Multiple Committers

How to share a repo with multiple committers.

1. Introduction

The traditional CVS-like model allows multiple different users to commit to the main repository. Indeed, it's about the only way to do things.

But in Mercurial, in some sense there is no 'main' repository. Users each have their own private repository to commit to and they can pull commits in from other users. This is rather drastically different than the CVS model and it has a number of advantages:

• it's easier to review the work that's being pulled in before merging
• it's easier to time or reorder merges for testing or deployment
• no concept of permissions is needed
• everything is atomic, no need to wait for locks

It is, of course, also possible to push as well as pull, though this is generally used to publish changes in a public place.

However, it is possible (though not recommended) to set up Mercurial to allow multiple users to push to a single repository. This allows Mercurial to be used in a more CVS-like fashion. Below are a couple possible approaches.

2. The filesystem method

The idea here is to create a repository that is accessible by members of a certain user group. Multiple users will be able to access it if they belong to this group.

The following steps apply to most Unix-like operating systems:

1. Add a new group to /etc/group. The recommended method for accomplishing this varies from system to system, but the end result is a new line in /etc/group like the following:

   project:x:100001:alice,bob,charlie

   Here, project is the name of the group.

2. Create a repository that's writable by that group:

   mkdir /home/mercurial/project
   cd /home/mercurial/project
   hg init
   chgrp project .hg .hg/* .hg/store/*
   chmod g+w .hg .hg/* .hg/store/*
   chmod g+s .hg .hg/store .hg/store/data

   • The chgrp command marks the project as belonging to the project group.

   • The first chmod command marks the repository data writable by that group.

   • Finally, the second chmod command sets the 'setgid' bit on the project directories, which causes new files created in those directories to be marked as belonging to that group (rather than the user's default group).

Future files created by Mercurial will inherit their permissions from .hg/store.

Now you're ready to go:

hg clone /home/mercurial/project
cd project
[make changes]
hg commit
hg push /home/mercurial/project

3. The shared SSH method

The simplest way to share a repo with SSH is to grant users SSH access to the server and set up permissions as above. Mercurial will invoke ssh to create a connection, then attempt to launch a copy of 'hg' on the remote machine to communicate with. Note that Mercurial's SSH URLs are relative to each user's home directory, so shared repositories may need a '~' or '//' in them to work. See [urls] for more info.

A method that is more restricted/controlled is to create a single account and distribute separate SSH keys for each authorized user. See the guide to shared SSH for general setup details.

4. The HTTP/HTTPS method

The repository will be shared via a web server, which can also allow pushing. The security is handled by the web server. See the guide to publishing repositories for some guidance.

CategoryHowTo CategoryTutorial