How To Handle Multiple Committers

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.

1. Traditional UNIX method

The idea here is to create a repository that has a group ID that allows multiple users to access it.

The first step is to add a new group toetcgroup. The 'kosher' method for accomplishing this varies from system to system, but the end result is a new line inetcgroup like the following:

project-x:x:100001:alice,bob,charlie

Then, we create a repository that's writable by that group:

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

The chgrp command marks the project as belonging to the project-x group. The first chmod command marks the repository data writable by that group. And 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).

Next, it's important that each user's umask be set to 002 or something similar. If it's set to 022, group write privileges will be masked off for files that users create, causing other users to be unable to modify them.

Now you're ready to go:

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

2. The SSH method

Rather than bother with UNIX permissions, shared filesystem, etc., you can instead create a repository that's reachable by SSH. The typical way to do this is to create a special account for that project, create the project under that account, then provide each user with an SSH key that's authorized to use that account. See http://www.kitenet.net/~joey/sshcvs/ for the general setup details.

3. The HTTPS method

This is not yet implemented, but the plan is to allow push over HTTPS with an internal authentication scheme. This will bypass both the need to manage UNIX groups and permissions, and the need to do special SSH setup.

4. Keeping in sync

You may sometimes get a warning like this when you push:

abort: unsynced remote changes!

This means you should pull the latest changes from project-x before pushing.

You may also get a warning like this:

abort: push creates new remote branches!

This means you've probably forgotten merge changes you've pulled with the changes you're trying to push.

As always, SyncEarlySyncOften.