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.
Related
I created a mercurial repository on some file servers net share.
Is it possible to automatically get the remote repository updated to tip if somebody pushes its changes?
Because some other people (purely users) may copy the repositories content (rather than cloning, because of lack of .hg) and i want them to get the newest version.
Since it is a share on a simple NAS it would be good if the pushing client could invoke this update.
It seems that a hook on the changegroup event can solve this.
Add the following lines to the repository's configuration file (repo/.hg/hgrc)
[hooks]
changegroup = hg update
This solution was suggested on a slightly different question:
Cloning mercurial repo to the remote host
At least under windows this seems only to work on local repositories. The reason for this is, that hg tries run a cmd on the remote path that fails, since it does not support UNC paths as current direcory.
Adding explicitly the repository url fixes this, but its not client independent anymore.
[hooks]
changegroup = hg update -R %HG_URL%
You could treat the server repository as your "local working directory" and then PULL from your own PC to that location. If you use hg pull --update then it will automatically update the working folder to the latest.
One way to do this is to login to your NAS and physically run the hg command line program there. If not, you could also mount the NAS folder on your local PC and then chdir to its mapped local folder and use your local hg client to do so.
This might seem like an odd thing to do but Mercurial doesn't care which is the "clone" and which is the "server", you can swap them interchangeably in your workflow.
I have a file default.config in the root of my repository. I tweaked it for my own setup, and I do not want to commit it. Ever. What are my options other than commit -X "^default\.config$"?
I added ^default\.config$ to .hgignore, but it still shows up in the output of hg status -mard.
Edit: maybe it's possible to do this with Mercurial Queues. If I keep all my local config changes in a single patch, then I just have to remember to pop it before committing. Just thinking out loud...
Follow these steps:
Copy the file somewhere outside your working directory
Remove the file with hg rm default.config and commit the changes
Copy back your file to the working directory
As a good practice you can add a file called default.config.template or something which is committed to the repository. This file holds some kind of default values or comments on how to use it and other users/developers can copy this file to default.config if they're using your project.
Akluth has the correct answer: commit a template file to your repository and then copy that to the real name in each working copy. If the config file supports it, then use an include directive to load the template file from the real config file. Something like
// default.config
//
// load defaults from versioned template file
#include "default.config.template"
// override defaults with my settings
db_hostname = localhost
db_user = me
An alternative is to use -X with every command, as you suggest. There is an exclude extension that implements this idea. Remember to read the caveats — it doesn't work when merging because you cannot exclude files when committing a merge. The extension would need to be extended to handle that case, probably by shelving change before the merge and unshelving it afterwards.
This suggests another stragety, similar to using MQ as you suggest: use the new shelve extension in a set of pre- and post- hooks to shelve/unshelve the file before/after each operation. I think that could work, though I haven't tried it in real life.
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.
Getting ready to launch a website/project that was in beta testing. I want to switch it over to version control (Mercurial since I'm familiar with it).
Problem is, I am not sure how to go about doing it since the code on the website is already up and in-use and how to deal with the directories I do not need to manage (vendor and web/Upload).
Whats the best way to go about this?
Would I put the entire site into a folder, init a Merc repo, use hgignore to not track vendor and web/Upload, commit, then clone it to the live server?
Thanks! Just confused on what to do since the site is live and has user uploads.
I'm assuming you want to turn the website directory on your web server into a Mercurial repository. If that's the case, you would create a new repository somewhere on that computer, then move the .hg directory in the new repository into the website directory you want to be the root of the repository. You should then be able to run
hg add * --exclude vendor --exclude web/Upload
hg commit -m "Adding site to version control."
to get all the non-user files into version control.
I recommend, however, that you write a script or investigate tools that will deploy your website out of a repository outside your web root. You don't want your .hg directory exposed to the world. Until you get a deploy script/tool working, make sure you tell your webserver to prohibit/reject all requests to your .hg directory.
Our company policy is not to back up hidden folders.
Is it possible to change the .hg folder name to something visible?
There's no way to rename that directory using standard mercurial configuration options. If you're on unix, and I'm guessing your are if .hg sounds hidden, you could use a pre-backup script (or cron job) to snapshot it using cp -al into something with a different name. Using -l gets you hardlinks, so it won't actually take up extra disk.
However, most people back up their .hg repositories with a push to a different mercurial server, which can be easily scripted too.
Can you create a tar archive of the repository before your company's backup cycle runs via cron?
You can always try to fool the back up system by creating a link to the .hg folder with a "backupable" name.