merging changes from a maven release branch yields

问题:

following standard practice, I have an svn trunk for feature development, and a forked-off branch for building releases. The branch has been created using the maven release plugin, which is also used for creating releases. As it happens, the occasional bug will be fixed on the branch, and those changes need to be merged back into the trunk. To not miss any changes, I'd like to be able to simply merge the complete branch back into the trunk.

Now my problem is that I get numerous conflicts in all my poms because project/dependency versions diverged in the branch and in the trunk, due to the release plugin incrementing version numbers. Does anybody have an idea how to restructure branch creation, my poms or releasing to avoid those merge conflicts?

回答1:

This is inherent in using Maven POMs and Subversion branches together in this way. You have a few options.

1. do your merges starting with a revision in SVN to avoid the commit that bumped the snapshot. Sometimes simpler, but not the ideal way to merge and can still end up with conflicts
2. check the conflicts and use mine-conflict (mc) as the option if POM changes are the only ones. If you're confident of this, you can use SVN's --accept mine-conflict
3. allow them to be incorrectly merged and use the Version's plugin to reset the version afterwards with versions:set

回答2:

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

Reorganise branching: The cause of the conflicts seems that the release plugin changes the trunk and branch versions after creating the Subversion branch. To work around this, I'll

1. bump the trunk version with versions:set.
2. use release:branch to create the branch, but set -DupdateWorkingCopyVersions=false because I've already set the version.

This will avoid the merge conflicts. What remains is that whenever I merge the branch back to the trunk, I'll now merge in the branch version too. Again, versions:set to the rescue.

回答3:

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

We tackled the same merging from branch to master problem, and moreover, developers were forgetting to run the versions:set and committing the wrong version in the master.

We created a git hook that prevents such wrong 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 manage the hook inside the git repo, and create a soft link in .git/hooks for it on each dev machine