Mercurial workflow question (how to handle Config files)

Question

I have a long standing problem: at work we\'re using mercurial as a DSCM, but we can\'t figure out how to keep our config files in sync.

The problem is that we want

Answer 1

If you can't deal with it with the inclusion of custom settings, just have a base config file in the repo.

Then have each developer put it's own customization on top (with mq). If the customization isn't too intrusive the merge will always go well.

There is another way, where you repeatedly merge your customization, but then when pushing you have to remember not to push the merge branch (tX is mainline, c1 is the customization)

t1-t2-t3-t4-...-tN
  \    \      \   \
   c1---c2-----c3--c4

The dev needs and push changes who only have tX as parents, cX should never escape the repo.

Answer 2

You can use Mercurial Queues to do it. So what you would do is have the "real" config(s) under hg (with their real names), and developers can maintain their customizations using patches which sit on top and are maintained with mq.

Then when developers need to update the real config, they pop their patch which holds all of their customizations off the stack, make the change to the config and commit+push it.

Presuming all other developers haven't overridden those particular changes in their own queues, they will receive them the next time they pull+update.

Answer 3

I don't know the details of your config files, but if you can include other files, then create a config_local file to hold the developer-specific settings. Add that file to .hgignore. Common settings go into the main config file, which then includes the config_local file.

As Ken says, if inclusion isn't an option, then preprocessing during the build step may be the way to go.

Answer 4

The non-DVCS way to handle it is to set up your build process to read the connection strings from separate config file and then preprocess it during the build process (in java you could use ant or maven to filter from a properties file, I don't know about MS-land).

Answer 5

Put your connection strings in a different file. e.g. in web.config:

<connectionStrings configSource="connections.config" />

Then you have a connections.config file with the connection strings, which you can exclude from the repository thereby letting each developer modify to their heart's content.

If you want a 'reference' version of the connections.config file just add another file connections.example.config that is under source control, and use that as your template version.

Answer 6

It's a bit of a bastardization, but you could use the KeywordExtension to automatically expand tokens. In your config file put something like this:

db.host = $DBHOST$
db.host = $DBUSER$
db.host = $DBPASS$

and then in their ~/.hgrc files user's would have something like this:

[extensions]
hgext.keyword=
[keyword]
# expand keywords in all python files in working dir
**.conf =
[keywordmaps]
DBHOST = dev.server.internal
DBUSER = myname
DBPASS = mypass

Production, of course, would have its own .hgrc.

The scheme would cost everyone a little bit of set up time once, but after that it should be automatic. Defaults could be in the system-wise /etc/mercurial/hgrc file in case the user didn't want to set their own private connection strings.