Simplest way to use mercurial to manage differences between web development and deployment?

I am using mercurial for website development. I "think" I'm using it correctly.

I develop on my development machine, commit fairly regularly. I will somewhat regularly push my commits to my hosted site-dev repository.

If things are set up how I want them for the live site, I push from my dev machine to the hosted site-live repository. Then I 开发者_StackOverflow中文版pull down from that repository onto the live server.

However, there are some changes that need to be made (changing directories from localhost to www.example.com, changing the DB connection stuff, etc.).

What I did was made these changes on my live machine, then pushed them back up to the site-live repository. I don't know why I did that, really, but at least there's a changeset sitting there with the necessary config changes.

What I don't know how to do is manage this process. I'm a little lost beyond committing, pushing and pulling with hg. I'm a single developer and haven't even done a merge yet.

Is there some way to keep that particular changeset identified, and just apply it, hopefully even BEFORE I pull from the repo down to the live server?

I think you can tell from my question that I'm in a little over my head with hg and workflow at the moment ;)

---

This is my understanding:

What essentially you are trying to do is have a development, staging and deployment environment. You do your development using 'development' repository, test it on a staging environment and then once satisfied, pull those changes into deployment repository. And when you pull from staging to deployment, you need to change your environment / configuration data.

My take is you should not be changing the configuration at all.

You should have configuration files such that you have a

1. basic configuration file

   basic.conf

2. Environment specific overrides

   basic.dev.conf, basic.staging.conf and basic. deployment.conf

3. Use environment variable:

   The overrides to the basic configuration data should be defined via an environment
   specific variable : APP_ENV : dev or staging or deploy

This way you should be able to override the configuration based on the environment without changing the configuration information.

It is not a good idea to rely on making changes to config files each time you pull your code from development to staging to deployment.

---

I would keep the live server outside the version control. Meaning that I would have a small "install" script that pulls updates from the repository, removes any unnecessary development files, and applies the correct configuration files. Both development and production configuration files should be in version control.