|
Size: 3735
Comment:
|
← Revision 26 as of 2015-04-29 15:01:20 ⇥
Size: 3587
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| = How To Handle Multiple Committers = | #pragma section-numbers 2 |
| Line 3: | Line 3: |
| 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. | <<Include(A:style)>> <<Include(A:dated)>> = Multiple Committers = How to share a repo with multiple committers. <<TableOfContents>> == Introduction == The traditional [[CvsLikePractice|CVS-like model]] allows multiple different users to commit to the main [[Repository|repository]]. Indeed, it's about the only way to do things. |
| Line 16: | Line 27: |
| == The Shared SSH method == The typical way to do create a SSH reachable repository 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 ["SharedSSH"] for general setup details. Another way is just to provide regular SSH access and setup the depot with the "filesystem method", below. == The HTTPS method == The repository will be shared via a webserver cgi-script, which also allows pushing. The security is webserver security. See HgWebDirStepByStep for general setup details. |
|
| Line 29: | Line 29: |
| The idea here is to create a repository that has a group ID that allows multiple users to access it. | 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. |
| Line 31: | Line 31: |
| The following steps apply to *nix operating systems. | The following steps apply to most Unix-like operating systems: |
| Line 33: | Line 33: |
| The first step is to add a new group to {{{/etc/group}}}. The 'kosher' method for accomplishing this varies from system to system, but the end result is a new line in {{{/etc/group}}} like the following: | 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: |
| Line 35: | Line 35: |
| {{{ project-x:x:100001:alice,bob,charlie }}} Then, we create a repository that's writable by that group: |
{{{ project:x:100001:alice,bob,charlie }}} |
| Line 40: | Line 39: |
| {{{ mkdir /home/mercurial/project-x cd /home/mercurial/project-x |
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 |
| Line 44: | Line 47: |
| chgrp project-x .hg .hg/* .hg/store/* | chgrp project .hg .hg/* .hg/store/* |
| Line 47: | Line 50: |
| }}} 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). |
}}} |
| Line 52: | Line 52: |
| 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. | * 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). |
| Line 54: | Line 56: |
| You can change the default umask for a user by editing their ~/.profile and adding the line 'umask 002'. Alternatively, you can edit /etc/profile to change the system-wide settings. | Future files created by Mercurial will inherit their permissions from `.hg/store`. |
| Line 59: | Line 61: |
| hg clone /home/mercurial/project-x cd project-x |
hg clone /home/mercurial/project cd project |
| Line 63: | Line 65: |
| hg push /home/mercurial/project-x | hg push /home/mercurial/project |
| Line 66: | Line 68: |
| == Keeping in sync == | == The shared SSH method == |
| Line 68: | Line 70: |
| You may sometimes get a warning like this when you push: | 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 [Topic:urls] for more info. |
| Line 70: | Line 72: |
| {{{ abort: unsynced remote changes! }}} This means you should pull the latest changes from project-x before pushing. |
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 [[SharedSSH|shared SSH]] for general setup details. |
| Line 75: | Line 74: |
| You may also get a warning like this: | == The HTTP/HTTPS method == |
| Line 77: | Line 76: |
| {{{ abort: push creates new remote branches! }}} This means you've probably forgotten to merge changes you've pulled with the changes you're trying to push. |
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 [[PublishingRepositories|publishing repositories]] for some guidance. |
| Line 82: | Line 78: |
| As always, SyncEarlySyncOften. | ---- CategoryHowTo CategoryTutorial |
|
This page does not meet our Note:
This page appears to contain material that is no longer relevant. Please help improve this page by updating its content.
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:
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.
- 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.