Force a manual Merge of certain files within TortoiseSVN

Question

Is there some way to force some files to not be merged automatically (force me to manage the merge) when merging a branch back into the main tree?

For example, I have web.config files that have specific paths based on whether I'm in the Dev or Production system. So, when I need to merge my dev branch back into main, I don't want to modify some of the tags, but other information might need to be updated.

The problem is that the merge may automatically update the settings that need to remain the same. I can easily revert back to the original, but then any new settings would be lost. It seems to be the easiest way to handle this would be for me to manually merge the changes in this case.

It's possible I'm coming at this from the wrong direction since I'm new to Tortoise and SVN.

In addition to the config example that has some good answers below. Is there a way to force all files to be handled manually during a merge? It seems like there should be a flag that could be applied to the files to simply make it look like there is a conflict to the flagged file and to handle the merge accordingly.

Answer 1

One way I've seen this handled is:

1. Keep your configs in separate directories (dev, uat, prod, etc.)
2. Check these in to SVN
3. Modify your build process so that it copies the appropriate config into the bin/ directory, based on a command-line parameter

Answer 2

I'd suggest looking at the question in terms of your Build or Deployment processes, not the Version control process.

Personally, I've used ANT with platform/environment specific properties to allow for one configuration file in SVN (or any other SCMS) that is either overridden in the local environment or has placeholders that get substituted during the build by platform/environment specific values.

I don't believe there is an easy or automate-able way to do what you're asking in TortoiseSVN

Answer 3

If you aren't concerned with sharing configuration information (such as database access), you could easily wrap the dev/prod specific sections in an if->then.

if (production) {
   db = prod
} else {
   db = dev
}

I've seen a few methods on determining environment, from the machine's physical name (good for limiting unauthorized use of code), to IP address, host name, etc.

An alternative that offers a little security and wouldn't affect the build process too much would be to use branches. Keep the production web.config in its own branch with matching directory structure, and merge that into a 3rd branch that has the latest production ready code. so:

/trunk <-- development (or its own branch)
/branches/
/branches/production-pre <-- latest stable
/branches/production-config <-- web.config and related only
/branches/production-post <-- final merged

Yes it puts more work on deployment, but it does offer security if that is the desired effect.

Answer 4

Can anyone actually answer the question asked, not the "how configure deployment process?" im actually facing the problem when automatic merge often results in loss of changes performed by different users, so forcing a manual merge (even if it's a single line change) seems like a solution to me, at least i'll know that its Pete or Bob merged wrong, not some abstract svn-issue happened.