Geek Answers Handbook

Force manual merging of specific files in TortoiseSVN

Is there a way to make some files not merge automatically (make me control the merge) when merging the branch back into the main tree?

For example, I have web.config files that have specific paths based on whether I am on a Dev or Production system. Therefore, when I need to merge the dev branch back into the main part, I don’t want to change some tags, but other information may need to be updated.

The problem is that the merge can automatically update the parameters, which should remain unchanged. I can easily return to the original, but then any new settings will be lost. This seems like the easiest way to handle this, for me it would be to manually merge the changes in this case.

Perhaps I am coming to this from the wrong direction, as I am new to Tortoise and SVN.

In addition to the configuration example, which contains some good answers below. Is there a way to force all files to be processed manually during merge? . It seems like there should be a flag that can be applied to files to just make it look like a conflict with the marked file and handle the merge accordingly.

+4
source share
3 answers

One of the ways I saw this is by:

  • Save your configs in separate directories (dev, uat, prod, etc.).
  • Check them out on SVN
  • Modify the build process so that it copies the appropriate configuration to the bin / directory based on the command line parameter
+2
source

I would suggest considering the issue in terms of build or deployment processes, not version control.

Personally, I used ANT with specific platform / environment properties to allow one configuration file in SVN (or any other SCMS) that is either overridden in the local environment or has placeholders that are platform / environment specific during assembly.

I do not believe that there is a simple or automated way to do what you ask in TortoiseSVN

+1
source

If you do not like to distribute configuration information (for example, access to the database), you can easily wrap certain sections of dev / prod in if-> then.

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

I saw several methods for determining the environment, from the physical name of the machine (good for restricting unauthorized use of the code), IP address, host name, etc.

An alternative that offers little security and does not affect the build process too much will use branches. Store the web.config file in your own branch with the appropriate directory structure and merge it into the 3rd branch with the latest finished production 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, he works more on deployment, but he offers security if that is the desired effect.

0
source

More articles:


All Articles