How do I tell subversion to always select my local version for conflicted merges on a specific file?

Question

I'm looking for a way to specify that a subset of files should not be changed when merging in modifications from a particular branch, using Subversion. I found someone asking the same question, but for git.

What I have is Maven pom.xml files, which are set up when the branch is created and updated for each release from the branch. When I merge changes back to trunk from the branch, I don't want the changes in these files to be merged (and they will actually always be in conflict, as the version numbers have been updated on trunk too). Is there any way to tell subversion to accept base for just these files, for the same effect as provided by the answer to the git question?

Someone else has asked a similar question, but put it in a context where the question was the wrong one to be asking (generated code).

Answer 1

You could either script setting the svn:mergeinfo property on the file to have it skip merging changes made on the branch. (See http://svnbook.red-bean.com/en/1.5/svn.branchmerge.advanced.html#svn.branchmerge.advanced.blockchanges)

When I merge maven projects, I use TortoiseSVN, and deselect the changes to the pom done by the release plugin, so it does not try to merge in the version changes. Of course, I also want the other changes to the pom to be merged, since most of those changes are dependency changes, and I want trunk to get those new dependency updates.

Answer 2

If you know that the files will always be in conflict then you could run svn merge with the option '--accept mine-full' which should ensure that all conflicts will be resolved by accepting the current version on your branch.

Edit:

I can't think of any nice way other than having a script that knows about these specific files and following a merge it will revert the contents of those files. That relies on running it manually every time you merge.

Another alternative approach would be not to have this files in source control at all, but generate them automatically as part of your build, and store the information about which version numbers are on each branch in another form, eg LDAP or Mysql, and generate them as part of your checkout or build process. We use this approach (though with the slight difference that we merge in these changes but the file contents get overwritten anyway on each build, so you don't care abut the conflicts).

Answer 3

Solution in my project: Don't have this file on Subversion, i.e. include it in svn:ignore.

If you still want to share the file you can have a copy of it like pom-example.xml under version control. For a central file like pom.xml it might be acceptable that developers are required to copy the file to the real filename after a fresh check out.