I have a setup as follows.
A private repository at bitbucket where I keep the ‘master’ repository.
A repository on my server which acts as the ‘live’ website.
A repository on my laptop which acts as my working copy.
My process is as follows. I make a change to a file in my local repository. I commit these locally. I push these changes to bitbucket. I then pull these changes from my bitbucket to the webserver.
The problem that I have however is that my local copy utilizes different configuration settings for databases, paths etc, ergo what I want is my ‘config.php’ file at bitbucket to contain the server settings, and the config.php on my local host to contain local settings.
I believe this can be achieved with .hgignore but i have had no success researching.
The problem i encounter is that i make my server settings file, push it to bitbucket, ‘forget’ the file in my local repository, create a .hgignore, and then recreate the file. However when i ‘forget’ the file TortoiseHG notices and asks me to commit the change to bitbucket….
Any ideas would be greatly appreciated.
Thanks
Additional Points.
Following the advice below I have developed a setup as follows:
I have my local repository on my laptop where i do my edits.
I have bitbucket which is essentially the ‘main’ repository – if any other developers join the team they clone this.
I have my live repository on my web host.
On my live repository I have a .hgignore file whichs ignores the respective config files.
As such when I do hg pull from my host, it pulls the repository as is with the localhost configuration files, but when i type hg update (to the live working copy), these files are ignored/not updated.
Could someone clarify as to if i have understood this correctly, and as to whether this is a suitable way of achieving what I want?
Thanks
.hgignoreonly ignores files if they are not versioned already, so I don’t think your idea in the question will work.The common approach regarding local configuration is generally a variation on the same theme, like of one of the following:
Do not check in the
config.phpat all. You can check in aconfig.example.phpwith the most common settings, and document in theREADMEthat users have to copy it toconfig.phpand then edit it.Put any shared settings in
config.php, and add an include statement to point to an unversioned file with settings specific to the machine, e.g.config.local.php. You can also provide anconfig.local.example.php-file for this.Like 2, but the
config.phpcontains all default settings and the local file has the ability to override them.Check in a
config.dev.phpandconfig.server.php-file containing the settings for both environments, and then have an unversionedconfig.phpwhich includes one of the above files. Advantage is that the configurations themselves are versioned and you can update them.Which of these variations to pick, or whether you make another variation, depends on your environment.