Geek Answers Handbook

Merging changes with maven release branch leads to conflicts due to changed versions in poms

Following standard practice, I have an svn trunk for developing features and an extensive branch for creating releases. The branch was created using the maven release plugin, which is also used to create releases. As it happens, a random error will be fixed on the branch, and these changes should be combined back into the trunk. In order not to miss any changes, I would just like to merge the entire branch back into the trunk.

Now my problem is that I get numerous conflicts in all my letters, because the project / dependency versions diverge in the branch and in the trunk, due to the extension versions of the extension versions. Does anyone have an idea on how to restructure the creation of branches, my priests or release them to avoid merge conflicts?

+4
source share
3 answers

This is due to the fact that along with the Maven POM and Subversion branches. You have several options.

  • perform your merges starting with the revision in SVN to avoid the commit that pushed the snapshot. Sometimes a simpler, but not ideal, way to merge, and can still end in conflict.
  • check for conflicts and use mine-conflict ( mc ) as an option if POM changes are the only ones. If you are sure about this, you can use SVN --accept mine-conflict
  • allow them to be merged incorrectly and use the Version plugin before the reset version after versions:set
+3
source

Based on Brett Porter's answer, I think I will do the following:

Reorganize the branch. The cause of the conflicts is that the release plugin changes the version of the trunk and branch after creating the Subversion branch. To get around this, I

  • remove the trunk version using versions:set .
  • use release:branch to create the branch, but set -DupdateWorkingCopyVersions=false because I already installed the version.

This will avoid merge conflicts. It remains that whenever I merge the branch back into the trunk, I will now merge into the version of the branch. Again, versions:set to the rescue.

0
source

We also have the same convention, but we use git: in the main branch, our version of maven is always 0.0.1-SNAPSHOT, and for each branch, maven is the BRANCH_NAME-SNAPSHOT branch.

We solved the same merge from the branch to the main problem, and, in addition, the developers forgot to run versions:set and commit the wrong version in the main.

We created a git hook that prevents such incorrect commits:

 #!/bin/bash # To enable this hook: # ln -s ~/src/common-arsbigdata/common-fw/src/main/resources/bin/pre-commit ~/src/common-arsbigdata/.git/hooks/pre-commit BRANCH_NAME=$(git symbolic-ref HEAD | sed -e 's,.*/\(.*\),\1,') echo "current branch: $BRANCH_NAME" for file in $(find . -name 'pom.xml' -not -path "*/target/*" -not -path "*/bin/*"); do VERSION=`head $file | grep "<version>" | sed -e 's,.*<version>\([^<]*\)-SNAPSHOT</version>.*,\1,g'`; if [[ $BRANCH_NAME == "master" ]]; then if [[ $VERSION != "0.0.1" ]]; then echo $file echo "expected version 0.0.1, actual version is $VERSION" exit 1 fi elif [[ $VERSION != $BRANCH_NAME ]]; then echo $file echo "expected version $BRANCH_NAME, actual version is $VERSION" exit 1 fi done

We control the hook inside the git repository and create a soft link in .git/hooks for it on each dev machine

0
source

More articles:


All Articles