I’ve recently had a regular task of releasing projects from multiple branches, and then merging branches together. Handling this and any conflicts hasn’t been a big hassle when it is regularly updated, with one notable exception – Maven POM files. When they are merged the version changes on both branches always conflict.
There are ways I’ve got around it to date:
--accept mine-conflictand similar options can help resolve them quickly if you know ahead of time they are the only conflicts, without additional changes
- If ending up with versions from the wrong branch, follow up with
mvn versions:set -DnewVersion=... versions:commit
- Sometimes the right merge tool or IDE will select the right one, or at least make it less repetitive to select the right one for each file
However, I was finding that in projects with a large number of POMs and occasional other conflicts, these were all a little too tedious. I’ve whipped up a basic script that can be used to eliminate the POM-based conflicts first, so that the remaining conflicts are only those you really need to deal with: Automatically resolve conflicts in Maven POMs after a merge — Gist. It doesn’t handle a lot of edge cases, but should work well enough for most uses.
This works pretty well with Git, and can be used with Subversion (if you automatically postpone all the resolve steps with
--accept, or use a non-CLI tool to merge).
This is not something I’d want in a standard release/branch workflow – the problem could be avoided by different branching practices so that release commits are not merged. However if someone finds it useful, I’m sure they can improve on the Gist above, or perhaps patch the Maven SCM or Versions plugins to provide the capability more directly.