I have a lot of things in my .hgrc file so I keep it in a repository and share it between computers.
I have a lot of extensions enabled in the [extensions] section, but I don't necessarily want to use all of them on all of my computers.
Unfortunately, whenever I try to use Mercurial with my shared .hgrc file on a computer where I don't have every single one of the specified extensions installed, I get a message of the form:
*** failed to import extension evolve from $HG_EXTENSIONS/mutable-history/hgext/evolve.py: [Errno 2] No such file or directory: '/home/botond/programs/mercurial/extensions/mutable-history/hgext/evolve.py'
every time I run any hg command!
Is there a way to avoid this? For example, is there a way to specify in the .hgrc file, "load this extension if you can find it, otherwise don't load it and just be quiet about it"? (Then, if I actually try to use the extension, I'd get an error.)
additional search terms:
How to conditionally enable Mercurial extensions
Activate Mercurial extension based on condition
Enable a Mercurial extension only if it exists
Use Projrc extension
Enable all and any extensions in projrc's config
Disable missing|not needed files in .hg/hgrc
Related
Is there any built in mechanism for editing a repository's hgrc config file using the Mercurial API? I'm writing an extension that requires storing some options in the config file, and I'd like to provide a command for do so (the options that need to be stored involve timestamps and would be a little tricky for users to edit manually).
The Mercurial codebase does not provide any automated way to edit hgrc files except when they're first created by a clone operation and then only to set the paths.default setting to the origin.
I'm trying to create a shared hgrc file with common extensions for Mercurial, so my coworkers can get a consistent experience and find useful tools. Enabling extensions that don't ship with Mercurial, though, is causing issues.
My main repo's hgrc points to a source-controlled, shared .hgrc file:
\Repo.hg\hgrc
%include ..\tools\hg\dev.hgrc
The shared dev.hgrc then enables extensions we keep source-controlled:
\Repo\tools\hg\dev.hgrc
[extensions]
hgshelve=tools\hg\hgshelve\hgshelve.py
fold=tools\hg\hgfold\fold.py
The problem is those extensions are only found when hg is run from the root Repo directory. Running it from a subdirectory gives errors:
E:\Repo\src>hg
*** failed to import extension hgshelve from tools\hg\hgshelve\hgshelve.py: [Errno 2] No such file or directory
*** failed to import extension fold from tools\hg\hgfold\fold.py: [Errno 2] No such file or directory
I want to refer to the repository's root without relying on anything except the relative path structure.
I've looked in the manual, but don't see any repository relative path options there.
It's not quite what you're looking for, but if your systems are puppet, chef, or package controlled you can easily gin up a package that drops files in /etc/mercurial/hgrc.d/ anything in there is executed for all users on every run. You could put the extension .py files and the hgrc snippets to enable them down there.
I'm using the Mercurial Convert extension to import data from a PerForce repository. The conversion appears to have worked correctly, but all the Windows line endings (CRLF) were replaced by unix endings (LF).
Is there a way to get this extension to leave the line endings alone?
While the conversion itself may change the eol style, you still can, in your new Hg repo, specify what eol you want to see for certain types of files on checkout:
See EolExtension.
When working with people on different operating systems, it can therefore be desirable to be able to checkout text files with the operating system native line ending representation.
This extension lets you specify how end of lines (EOLs) are converted between the repository representation and the working copy representation.
I was able to do what I wanted using the "Perfarce" extension for Mercurial. The line endings for the mercurial repository will follow the settings of the "LineEnd" property of the Perforce workspace you are using. The steps were the following (on Windows):
Clone the Perfarce repository (https://www.mercurial-scm.org/wiki/PerfarceExtension)
In the mercurial.ini file of your user folder, add the configuration information described https://www.mercurial-scm.org/wiki/PerfarceExtension
Create a Perforce workspace that maps desired parts of the Perforce repository to the root folder for the workspace on the local computer
Update the local workspace
Open a command line at the parent folder of the desired mercurial repository folder
set P4PASSWD=your_perforce_password
set P4USER=your_perforce_username
hg clone p4://perforce_server_ip:perforce_server_port/your_perforce_workspace_name destination_folder
The resulting hgrc file for this repository is set up to pull additional changes from the Perforce repository, so it could conceivably be used on an ongoing basis, but I didn't use that.
My understanding: Mercurial has three levels of config files: one shared by all users (installation level), an overriding one for each user (user level) and an overriding one for each repository (repo level).
The HGRCPATH environment variable appears to override the second level, the one found in the users/<user> directory in Windows.
However in TortoiseHG's settings screen, it refers to (and allows direct edit of) the user level config file in the users/<user> directory, even when overridden by HGRCPATH. Quick experimentation has shown that TortoiseHG indeed uses the one set by HGRCPATH, not the one it indicates.
Is this a bug with Tortoise or is my understanding of HGRCPATH flawed?
Yes, this must be a flaw in TortoiseHg. The hg help environment help text says that HGRCPATH is used to override the default search path for configuration files. This includes ~/.hgrc and lets you quickly disable your user settings:
$ HGRCPATH= hg log # <- only read .hg/hgrc, ignore all other config files
You cannot make Mercurial skip reading .hg/hgrc.
The description in the Mercurial manpage makes it sound like if HGRCPATH is set then both the system-wide file (/etc/mercurial/hgrc on linux) and per-user file are ignored, but that the $(hg root)/.hg/hgrc file is still consulted. That's been my experience outside of tortoisehg.
I wouldn't expect the tortoisehg GUI to not-show the hgrc commands its not invoking, just to not take in their settings. Is that what you're seeing?
http://www.selenic.com/mercurial/hg.1.html
I have a project using mercurial for version control, SCons to build, and google test to write unit tests. The hgrc file hooks pre-commit and runs SCons to build the project and and run unit tests. Is there a way to "check-in" a portion of the hgrc file so that newly checked out copies, and any merges with my version of the project automatically get an hgrc file that runs SCons when they try to commit?
You can't get people to automatically have entries in their .hg/hgrc when they clone -- doing so would make it possible for someone to put rm -rf ~ in a commit hook, and wouldn't that be a bummer for the erstwhile cloners.
What you can do is include a file named something like mandatory.hgrc outside of the 'hg directory and then tell cloners to put this line in their .hg/hgrc:
%include ../mandatory.hgrc
Though that's still showing an awful lot of trust in you.
If you control the machines, as in many corporate settings, you can have your package/deployment/update tools (we use puppet) put whatever you want in their /etc/mercurial/hgrc file.
You cannot checking anything under the .hg folder. What my team does it that we have a common mercurial.ini file which as part of the dev box setup we put in our user profile folders.