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.
Related
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
I version controlled a project settings folder a couple months back on my default branch, and then over time created many branches off default. Now I've decided that I'd rather not have the project settings folder version controlled as it creates a lot of problems when switching between branches.
So I've hg forget'd this project settings folder which lets me keep the files on my local machine but removes them mercurial. However, when switching from one of the old branches which still have this folder versioned back to the default branch it actually removes the files from the local machine, which is bad.
How do I prevent that?
The folder is also in .hgignore on default now.
It's impossible to do.
But the common practice is to keep config.ini.dist in your repository and build environment-specific config by some build-system right after you check source code out.
The standard way to deal with this is to version control a template config file and ignore the real config file. The real config file can then include the template file, or maybe the template file is copied over once in a while.
The underlying reason for your problems is that running:
$ hg forget config.ini
is exactly the same as running:
$ hg remove config.ini
$ hg cat config.ini > config.ini
The forget command leaves the file behind in your working directory, but what you commit is still a file removal. This means that afterwards, Mercurial cannot distinguish between "file was forgotten" and "file was removed" — only the removal is committed, so the two commands look exactly the same.
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 created a repository on a remote machine using:
hg init
hg add
hg commit
The repository was created.
I cloned the repository on a local machine with no errors reported; The files seem to be there
Now I'm trying to make a clone of the clone (as a working copy) using:
hg clone "path to original clone"
It returns:
destination directory: "name of repository"
abort: No such file or directory: "path to original clone"/.hg/store/lock
What am I doing wrong?
Thanks
What filesystem is used on the partition where the main repository is ?
Actually, when Mercurial is doing some operations, it needs to lock the repository. For doing this it creates a symbolic link to an nonexistent file, when the filesystem supports it, in the .hg repository, telling every other processes that the repository can't be modified at this time. When symbolic links aren't supported by the filesystem, a normal file is created.
However, there's some problems with some FUSE filesystems, typically SSHFS with the follow_symlinks option activated. FUSE reports that he knows about symbolic links, but since SSHFS follows the symbolic link and the file doesn't exist, the "state" of the link is marked as unknown thus Mercurial thinks the repository isn't correctly locked and abort the operation.
I see you're using Cygwin, so maybe it's the same kind of problem with tools designed for UNIX on a windows filesystem. It's a strange, coworkers of mine are using Mercurial via Cygwin just fine.
I don't know if it's the case for you, but I lost nearly half a day on this problem. Maybe this answers can help some people in the future.
Please paste in the actual command that's failing and the output including the actual path to the clone that you're cloning. When you do the clone use --debug and --traceback too.
As a workaround you can can always try hg init newclone followed by hg pull -R newclone pathtooriginalclone, which is effectively equivalent except it doesn't use local hardlinks when possible.
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.