I have a mercurial repository with two permanent branches, default and UAT. Every once in a while, we deploy (promote) a new version of our application to the UAT environment and we do this by merging a stable default commit across to the UAT branch. Occasionally things will get bug-fixed in the UAT branch, and these bug-fixes get merged back to default.
On the UAT branch I need to change a few things for deployment purposes - connection strings and various environmental settings. What I tried to do was to make these change in the UAT branch and commit them (all as one commit) right after having merged default into UAT. I then dummy-merged this one commit back onto default - the thinking being that because default now has this commit in its ancestry future bugfix merges from UAT onto default will not try to redo these UAT-specific changes.
However things have not gone as smoothly as I had hoped. Starting with the dummy-merged commit onto default, I've tried both of the following scenarios:
1) Make a few more commits to default and then "promote" to UAT (merge default onto UAT)
2) Make a bugfix on UAT and "backport" it to default (merge UAT onto default)
In between running #1 and #2 I've stripped everything out so that both scenarios start from the same point.
What I'm seeing is that depending on the last direction merged I still need to inspect the changed files after doing one or the other merge and revert - sometimes the merge tries to put the default configurations into UAT and sometimes the UAT configurations into merge.
If I revert the configuration changes and commit the merge, then future merges in the same direction behave properly, but the minute I go in the other direction, the merge again puts the wrong configurations into the files.
What am I missing?