If Mercurial does not track file permissions by default, how does it decide on the permissions for any files/directories it creates?
Does it use umask? If not, what does it use?
I have read in the mail list the following:
Mercurial uses the mode of the .hg/store directory to compute a mask
but this seems a bit arbitrary (if there is any explanation behind it, I'd love to hear it). Is this explained in the documentation?
There doesn't seem to be any complete explanation, only a mention of it in the "How To Handle Multiple Committers" page:
If you are using a version of Mercurial older than 1.0, 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.
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.
Changing the /etc/profile will not work if people check in stuff with the hg command, as that file isn't read by non-interactive shells, /etc/bash.bashrc is a better place to put the system-wide settings.
Otherwise since Mercurial 1.0, the default permission is inherited from .hg/store.
Related
I have a centos server with code maintained using a mercurial repo.
To allow a new person to commit code to mercurial, I create a new user, add them to the webdev group, and they can push / pull code by
hg pull ssh://name#server.com.
However, there are some files (config files) that I would not like new users to have access to. Mercurial has been asked not to track these files, so the only way to access them is to ssh into the system and look at the files. Which I dont want new users to be able to do.
In essence, I want my new developers to only pull/push files through hg and disallow ssh-ing directly into the system. What the best way to do this? Can I provide hg access to a repo without providing ssh access to the files?
(or is my approach to the problem flawed?)
Thanks!
This can be really easily done by taking advantage of the command option available in .ssh\authorized_keys files. When you're granting their key access in that file you can prepend a "command=...." argument to their key and that's the only command they can run.
Mercurial ships with a handy script for doing exactly that. It has instructions inside:
https://www.mercurial-scm.org/repo/hg/file/tip/contrib/hg-ssh
In term of an authorization layer (similar to Gitolite for Git), you have mercurial-server (not to be mixed up with the Mercurial light-weight web server hgserve)
mercurial-server gives your developers remote read/write access to centralized Mercurial repositories using SSH public key authentication; it provides convenient and fine-grained key management and access control.
See its repository here.
It is based on the same SSH forced-command mechanism than the script mentioned by Ry4an in his answer (+1 on his answer, because it is already packaged with Mercurial).
See for illustration the "mercurial-server" source of refreshauth.py.
Is there any way to centrally manage mercurial settings for all users of a repository? Are there additional [existing] tools, add-ons, extensions, etc for this?
My use case
We have a repository that includes a few Excel, Word etc files that constantly cause trouble with merging.
With [merge-patterns] entries a la **.doc = internal:fail I can specify the intended behaviour, but I have to set this up for each and every user.
I want this to propagate automatically to anyone who clones the repository.
Environment
We use Kiln 2.6 hosted on our own Windows Server and TortoiseHg 2.2 on our Windows clients.
As far as I know, this possibility doesn't exists in Mercurial and I'm not aware of any extension which let you clone the .hgrc along with the other files.
However, you can do some things to "ease" the process of setup for each user.
Provide a template hgrc in the repository
You can add a "template" .hgrc in the repository. When a user clone the repo, the only thing he as to do is move the template to the right place.
Change the system wide hgrc
If you have some kind of Configuration management system for your clients, you can set the system wide configuration file for each of your users. There's various way of doing it. From the documentation:
(Windows) <install-dir>\Mercurial.ini or
(Windows) <install-dir>\hgrc.d\*.rc or
(Windows) HKEY_LOCAL_MACHINE\SOFTWARE\Mercurial
Per-installation/system configuration files, for the system on which
Mercurial is running. Options in these files apply to all Mercurial
commands executed by any user in any directory. Registry keys contain
PATH-like strings, every part of which must reference a Mercurial.ini
file or be a directory where *.rc files will be read. Mercurial checks
each of these locations in the specified order until one or more
configuration files are detected. If the pywin32 extensions are not
installed, Mercurial will only look for site-wide configuration in
C:\Mercurial\Mercurial.ini.
But obviously this depends on the way your clients are set up, so you will have to find the solution yourself. For example you can:
Set these files on the computer installation
Provide an executable which configure this that every user must run
Configure your in-house configuration management system to set up this on the next computer start
Change the roaming user profile if they have one.
You can use the projrc extension to push a project configuration file to others. It requires that the clients enable the extension first and that they fully trusts the server.
Would anyone know how I can restrict users from pushing to an hg repository if I give then access via hg-ssh?
Some details to help eliminate the obvious:
1) This is a for a shared hosting situation where I don't have root access to install mercurial-server nor can I create the "hg" username that it requires.
2) When I allow a user to connect via SSH to a shared hosting site, they will basically have their public key in my authorized_keys file and they will have be authenticated as me (i.e. they will have my credentials on the server). I can restrict their access to only a few hg repositories by specifying a "command=" clause in my authorized_keys file as documented here: https://www.mercurial-scm.org/repo/hg-stable/raw-file/tip/contrib/hg-ssh. However that gives the user full access to these repositories. Can I restrict this to pull-only access?
Any of these would solve my problem:
1) I know that mercurial-server solves this problem somehow because all the users their share the same user account called "hg". How do they do it? Can I do the same without root-access to set up things?
OR 2) Is there is a patch that I can add to hg-ssh such that hg-ssh can take some permissions on its command-line. Something like "hg-ssh -read-only repo1 repo2 -read-write repo3".
OR 3) Get "hg -R {repo} serve --stdio" to take a command line option such that it will not allow push.
The quick and dirty way would be to tweak the command= value to be something like this:
command=hg-ssh --config hooks.pretxnchangegroup=false repo1 repo2
but that's just the AclExtension done sloppily.
mercurial-server gives you the simplest control over this. You can install it as a non-root user, but you have to take a little longer to understand how it works.
Use the AclExtension. It lets you block access for ssh actions as well as http actions, and since it's enabled/disabled by hooks you'll be able to bypass it when you're logged in interactively.
we are working with mercurial and now we would like to introduce precommit hooks to keep the code clean. We would like everyone to somehow get the hooks, but we would also like to be able to update this in some centralized way. Mercurial does not version control hooks, so what would be our alternative option?
Do any of you have found a solution for this?
Thanks in advance!
Nemmi
Hooks are not cloned (as detailed in "Version-controlled extension configuration in Mercurial"), but you can have a common hgrc file (see hgrc Syntax):
A line of the form %include file will include file into the current configuration file
In that central configuration file, you can then modify the [hooks] section.
If you have control over their desktops (it's a standard corporate install) you can put the hook in the system-wide entries /etc/mercurial/hgrc or /etc/mercurial/hgrc.d/ourcommithook
If you're remotely administering the machines you could automate this using something like the very excellent puppet or by building your own .rpm, .deb, or .msi installer which both installed Mercurial and places the everyone hooks in the machine-global config.
Have a look at the projrc extension. You then simply need to have designers put a small number of common lines in their ~/.hgrc files and they will automatically get pushed whatever you put in your centralized repo's repo/.hg/projrc file.
You will still need a common place to put these hooks but you probably already have some sort of shared mounted drive that users all mount, right? Or you could have a "tools" repository that everybody has to have checked out in a standard location.
Steve
I installed mercurial 1.5.1 on win xp but the files listed in hg help config, were not created.
Namely:
%USERPROFILE%.hgrc (is that a valid windows file name?)
%USERPROFILE%\Mercurial.ini
\Mercurial\Mercurial.ini
C:\Mercurial\Mercurial.ini (no such directory altogether)
%HOME%.hgrc (what is this directory)
%HOME%\Mercurial.ini
HKEY_LOCAL_MACHINE\SOFTWARE\Mercurial (no registry created)
.hg\hgrc (i had to create this file manually to solve my problem)
They're not supposed to be automatically created. They're places you can put configuration information depending on what scope you want it to have:
C:\Mercurial\Mercurial.ini - If you choose to create this whatever you put in it affects all users on the systme
%USERPROFILE%\Mercurial.ini - If you choose to create this whatever you put in it affects only you, but in every repo with with you interact
((repository root))\.hg\hgrc - If you choose to create this whatever you put in it affects only the repository in which you placed it
So, it's all about scope. Something like enabling an extension might be best done system global in C:\Mercurial. Something like setting your username is probably best done only for you, in your %USERPROFILE%\Mercurial.ini. Saving a password for a repository (if done at all) probably goes inside that repos .hg/hgrc file.
As explained by Daniel in the comments, %USERPROFILE% is the expansion of an environment variable. That's necessary because your home directory location differs depending on what version of windows you have, how your administrator configured it, and your name.
AFAIK, the files are not created by default. For storing the login IDs, it's usually a good idea to do what you did, especially if you have a different username for each project you work on.
Otherwise, you could create a Mercurial.ini file under C:\Documents and Settings\<user name>\ (as you are using Windows XP) or under C:\Users\<user name> (if you're using Windows Vista or Windows 7)