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 to keep track of config files and want to be able to exchange the config file contents among developers, but every developer wants to have his connectionStrings section independent of others'.

Is it possible to somehow keep config files tracked but to omit the connection strings section when pulling and pushing?

We tried adding config files to .hgignore but when someone adds something important to config file we have to share it by email.

Thank you.

Answer 1

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 2

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 3

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 4

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 5

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.