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.
Related
I am using Jenkins for our build server. I have multiple projects using the same Mercurial (Hg) repository and want to avoid each project cloning it's own local repo to build from (since the repo is rather large). This is supposed to be possible via Jenkins and the Mercurial plugin.
In my Mercurial plugin configuration I have checked both "Use Repository Caches" and "Use Repository Sharing". In each project, the same repository location (a network location specified via IP address) is listed.
However, each project still seems to want to create a clone of the repository. Any ideas?
In our setup (using Jenkins 1.506), I've defined a custom workspace under the Advanced Project Options for each of my builds, typically at [project]\repo and then build from there into a \build\ folder.
If you define the custom workspace for each Jenkins project to point to the same shared custom workspace using the same source for the repo it will reuse what is already there.
I've not tested this, but I would assume that under this setup, it is important to prevent concurrent builds from occurring in the same working directory. Bad things would follow.
As a followup question: What is your rationale for not wanting each build to have its own source code?
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.
We are using TortoiseHg as our Mercurial client UI. Today we ran into an issue while trying to push from one particular workstation. It was receiving the following error:
abort: No space left on device
[command returned code 255 ..........]
This error occurs while TortoiseHg/Mercurial is bundling files in preparation to pushing to the repository. I did some testing and noticed that the workstations (C:) drive was gradually being filled up as the file were being bundled. The (C:) drive went from ~900MB to ~100MB and then the error message was received. So this is obviously the cause.
My question is this:
Does anyone know which default directory is used to store the temp files created while TortoiseHg/Mercurial bundles files in prep for a push? This seems to be independent of the drive TortoiseHg is installed to. I re-installed to a data drive with plenty of space and still used (C:) to store whatever temp files it was using.
Is there a way to configure TortoiseHg/Mercurial to use a temp directory of your choice?
Thanks in advance for any help!
Mercurial is python and python has good platform specific defaults for temporary file locations. They're pretty easily overridden if you want something other than the defaults, which on Windows are probably c:\temp.
http://docs.python.org/library/tempfile.html#tempfile.tempdir says it's:
The directory named by the TMPDIR environment variable.
The directory named by the TEMP environment variable.
The directory named by the TMP environment variable.
A platform-specific location:
On RiscOS, the directory named by the Wimp$ScrapDir environment variable.
On Windows, the directories C:\TEMP, C:\TMP, \TEMP, and \TMP, in that order.
On all other platforms, the directories /tmp, /var/tmp, and /usr/tmp, in that order.
As a last resort, the current working directory.
So if you've got software using Mercurial on a client computer set the environment variable to some place you know has space.
Mercurial always stores internal files inside the ".hg" folder in the local repository folder.
Maybe TortoiseHg has a additional temp folder... don't know. Anyway you should try to push the files using the Mercurital command line client:
hg push
More information about the command line client you can find here Mercurial: The Definitive Guide
Another temporary solution might be the move these files via a file system simlink to another drive with more space left.
I know it is not possible to create Mercurial repositories remotely using HTTP(S), for instance:
$ hg init https://host.org/repos/project
or
$ hg clone /path/to/local/project https://host.org/repos/project
But, what's the reason? Security issues? No need for it? Simply because nobody has implemented it yet?
Rationale for this question: In my company we share most resources via HTTPS, i.e. access permissions are managed by Apache only and regular users cannot login via SSH on the server. That's just perfect as long as repositories need to be served only (for that purpose we are happy with hgwebdir.cgi). However, we also want to allow the remote creation of repos, without the need to maintain additional/patched scripts on the server and extra tools on clients.
To be clear: This question does not ask for solutions to our particular problem but for the reason why Mercurial does not support this feature itself.
UPDATE
Here's a more technical description of the situation I'm thinking of. Supposed hgwebdir.cgi serves a collection of repositories in /path/to/repos at https://.../repos (with pushing enabled). Every user allowed to access this URL (as configured in Apache) may pull and push changesets, effectively this means that hgwebdir.cgi (and thus hg) edits and creates files below /path/to/repos. Now, what's the barrier in letting hgwebdir.cgi also create new repositories below /path/to/repos?
I think the reason is that adding support for creating repositories will bring in a fair amount of baggage:
if you can create repositories you would expect to be able to delete them. While that might seem simple, it would be a big step away from the safe manner in which Mercurial normally works -- there is no destructive commands in standard Mercurial.
people would also want to edit the .hg/hgrc files to set the description and contact information -- standard Mercurial never changes the config files, so this would again be a new thing.
people would also want to manage users' access to the new repositories -- this means editing .htaccess files or the equivalent for other webservers.
... and so on. Implementing this "little" feature will open up for a lot of extra feature requests and we only have a few Mercurial developers that are also sawy web developers.
However, there is now an excellent open source solution: Kallithea gives you a "mini-Bitbucket" that you can deploy on your own server. It will do all of the above. I would install that on my server if I needed something more powerful than plain hgweb.cgi. It supports both Mercurial and Git.
As far as I know, none of the SCM alternatives allow the creation of remote repositories natively. SVN, CVS, Git, et al.
That's usually the job of a hosting provider: SourceForge, Google Code, BitBucket. All of them implement the repository creation on top of their authetication infrastructure.
For example, Debian's Mercurial hosting is limited to Debian Developers, and to create a new repository you need to login via SSH to the server and create the repository on your local home folder, much like Apache's public_html directory.
Various answers (including your own) give some pretty good reasons why the functionality isn't there (separation of concerns mostly), but if you really want to add it you could do so with just a line or two of shell. Here's a hideously unsafe example I gave quite a while ago showing how to add that funcionality in high trust environments: Remote Repository Creation in Mercurial over HTTP
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