In my current project I have followed the usual advice for configuration files: Commit configuration files as templates, then copy them to another location so that configuration settings don't end up in the change history.
However, it is nice to be able to track the history of configuration files as well -- for all the same reasons that version control is useful in a single-user setting. What is the best way to set this up, on a clone that I use for development?
Background:
For deployed clones, I have been doing this by switching a new branch, say localconfig, adding the configuration files to it, and merging updates from default as they come in. This works fine.
But when doing development, it is a pain to worki in the localconfig branch: each commit has to be somehow rebased to default (or whatever branch I'm developing in), then merged back into localconfig. So I have kept the configuration files uncommitted on my development clone.
What's the best way to have it both ways? Basically, I need to either work in localconfig but easily commit to default, or work in default but have the configuration files present (so that the software can run).
I'm leaning toward the second option, perhaps something like this:
- commit the configuration to
localconfig - switch to back to
default - Extract untracked copies of the committed files, e.g. with
hg revert -r localconfig.
But when I make changes to the configuration files, I'll have to switch to the localconfig branch and commit them. That's just begging for problems with merging conflicts, untracked files blocking the switch to localconfig, etc. Does anyone have experience with this or a good solution?
I use mercurial, but I expect the question applies with any modern DVCS.
