I have a file with database settings in my project which I have set to some defaults. The file is tracked by Mercurial and checked in. Since this file will be edited with different values various developer machines, is there a way I can tell Mercurial to ignore new changes to this file?

I tried adding the file to the .hgignore file, but since the file is tracked it isn't ignored. This is alright and good in other situations, but I am wondering if there is something I can do here?

I realize this is very old now, but just in case - would you then have an install script that copies all template files to their functioning filename?
–
NickJun 18 '13 at 17:28

That would be a good idea. Don't forget to make your script ask for the configuration values, as they may differ from the template file, which is here to show the structure of the file
–
yanjostJun 26 '13 at 13:54

This is a really great idea, until you try committing a merge. When committing a merge, you are not allowed to specify files or patterns. So with that in your .hgrc,it doesn't seem to be possible to commit a merge at all without first editing .hgrc. Does anyone have a solution to that?
–
YitzFeb 13 '14 at 10:28

We wrote an extension for this called exclude. It will automatically add the -X options on the commands that support them -- so hg status and hg commit wont see the modified file. It works by reading a .hgexclude file from the root of your repository, just like the .hgignore file. You add the files that you want to exclude there:

syntax: glob
db.conf

The extension works quite well, but there is a known situation where it fails: merges and the commit that follows a merge (this is documented on the wiki). It would need to be improved so that it would save the modifications away to a temporary file and then restore them afterwards. Please get in contact if you need this feature.

If you are using TortoiseHG, open the Settings for the repo, go to the Commit section (2nd icon down on the left) & add the file name(s) to the Auto Exclude list on the right (~ 3rd from the bottom in the list).

This answer is equivalent to Irish's answer. The problem with it is that hg forget removes the existing contents of the file from the repository, which the OP didn't want.
–
BrilliandNov 27 '13 at 22:53

Typically you would check in a reference copy of the file and track it then have the developers make a copy of that for local development, you wouldn't really want developers editing the source controlled file for their own environments.

If your configuration system supports it, it's even easier if you can use an override file that simply override values in the reference copy (e.g. the database connection string). That way devs only have to keep a very minimal local set of override values.

If the file is already being tracked, you can issue the Forget command to the file. If you're using TortoiseHg just right click the file during commit and select Forget. The file must also be already in the ignore list.

I had the same problem as yours, I file keeps on appearing on every commit even-though its already in the ignore list. I tried the Forget command and it did the trick.

The two flags together claim that the file has been removed, and that the changes should be forced (rather than the removal should be forced as the help suggests). The help and documentation for the A (after) and f (force) flags are apparently not 100% accurate.

Worked for me in Mercurial 2.0, with the caveat that the archive command does not include the file, either. If other developers are cloning the repo, though, it shouldn't be a problem. They'll get the original version, and it shouldn't be removed from their working directory.

This doesn't actually work: the file is removed from version control which means that it's not part of a new clone. It will also be removed if you do hg update: think of it like a normal hg remove that just happens to leave the file behind in your working copy. Other clones wont "see" the --after and --force flags so for them it's just a normal removal and so the file is deleted when they update.
–
Martin GeislerMar 29 '12 at 7:10