CODEWITHSUNDEEP
mercurialweb-config
Ilya.R
Ilya.R

Reputation: 41

Mercurial : using general web.confg

We are using Mercurial for .Net Mvc applications. When we merge our branch we are faced with the problem that in web.config we have a different connection string

e.g.

connectionString="data source=Dev1\MSSQLSERVER2012;Integrated Security=SSPI;AttachDBFilename=|DataDirectory|aspnetdb.mdf; User ID=sa; Password=pass1

Second web.config

connectionString="data source=Dev2\MSSQLSERVER2012;Integrated Security=SSPI;AttachDBFilename=|DataDirectory|aspnetdb.mdf; User ID=sa; Password=pass2

etc.

How we can merge our configs without editing and rewriting the config again and again. Just ignoring the web.config file doesn't help. Does Mercurial have an "ignore file section" option?

Upvotes: 2

Views: 403

Answers (3)

alexis
alexis

Reputation: 50220

I have the same situation: Local configuration that I want to prevent from propagating, but I want to be able to push and pull the same files. Instead of messing with patches, I've been doing it as follows:

Let's say the regular takes place in branch default (there could be multiple branches; this is just for concreteness).

  1. Update to a clean latest version of default, without config state.
  2. Create a new branch, local. In this branch, commit all the local configuration as one or more changesets.

  3. At the tip of local, create a new branch, dev. Develop your new feature here.

    Your history now looks like this:

    ...o--o      (default)
       \
        L--L    (local)
            \
             d--d--d  (dev)

  4. When you're ready to push, rebase the entire dev branch onto the tip of default: 

    hg rebase --source "min(branch('dev'))" --dest default --detach

    If your feature has its own branch name that you want to keep, add --keepbranches to the rebase options. The previous tree becomes:

    ...o--o--d--d--d   (default)
       \
        L--L    (local)

  5. You can now publish the new features with push -r default without dragging along the local revisions. (Never merge from local into default; only the other way around). If you forget to say -r default when pushing, no problem: Your push gets rejected since it would add a new head.

  6. Still on the development server, merge the rebased revs into local:

    ...o--o--d--d--d   (default)
       \        \
        L--L-----N    (local)

  7. You can now create a new dev branch on top of local, and continue development.

This way my local configuration is under source contol; if it conflicts with a new feature, I can resolve it like any other merge. And if something should go wrong, I can update back to configured older versions.

My case also involves configured clones under revision management. You can see the full solution in this answer.

Upvotes: 2

Lazy Badger
Lazy Badger

Reputation: 97395

Use MQ and create (one or two) patches, which convert identical, common for both branches vanilla web.config into branch-specific state

Upvotes: 1

Steve Kaye
Steve Kaye

Reputation: 6252

Not a Mercurial answer but can't you change the connection strings to refer to localhost instead of Dev1 and Dev2? You'd also need to change to Windows authentication so that you don't need to have a password in the config file.

That's how we do it in our team and we never have any problems.

Upvotes: 1

Related Questions