объединение изменений из ветки релиза maven приводит к конфликтам из-за изменения версий в poms - PullRequest
Новая
       34

объединение изменений из ветки релиза maven приводит к конфликтам из-за изменения версий в poms

4 голосов
/ 24 августа 2010

Следуя стандартной практике, у меня есть соединительная линия svn для разработки функций и разветвленная ветвь для сборки релизов. Ветка была создана с помощью плагина релиза maven, который также используется для создания релизов. Как это случается, случайная ошибка будет исправлена ​​на ветке, и эти изменения должны быть объединены обратно в ствол. Чтобы не пропустить какие-либо изменения, я хотел бы иметь возможность просто объединить всю ветку обратно в ствол.

Теперь моя проблема в том, что я получаю многочисленные конфликты во всех моих poms, потому что версии проектов / зависимостей расходятся в ветви и в стволе из-за увеличения номера версии плагина выпуска. У кого-нибудь есть идеи, как реструктурировать создание веток, мои poms или релизы, чтобы избежать конфликтов слияния?

Ответы [ 3 ]

4 голосов
/ 24 августа 2010

Это присуще совместному использованию Maven POM и Subversion. У вас есть несколько вариантов.

  1. выполняйте слияния, начиная с ревизии в SVN, чтобы избежать фиксации, которая повлияла на снимок. Иногда более простой, но не идеальный способ слияния и может привести к конфликтам
  2. проверьте конфликты и используйте mine-conflict (mc) в качестве опции, если изменения POM являются единственными. Если вы уверены в этом, вы можете использовать SVN --accept mine-conflict
  3. разрешить их неправильное объединение и использовать плагин Версии, чтобы впоследствии сбросить версию с versions:set
0 голосов
/ 30 декабря 2013

У нас тоже есть такое же соглашение, но мы используем git: в основной ветке наша версия maven всегда 0.0.1-SNAPSHOT, а для каждой ветви maven ветка BRANCH_NAME-SNAPSHOT.

Мы взялись за решението же самое слияние ветки с мастером, и, кроме того, разработчики забыли запустить versions:set и зафиксировать неверную версию в мастере.

Мы создали ловушку git, которая предотвращает такие неправильные фиксации: 

#!/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

Мы управляем хуком внутри git-репо и создаем мягкую ссылку в .git/hooks для него на каждой машине разработчика

0 голосов
/ 25 августа 2010

Основываясь на ответе Бретта Портера, думаю, я сделаю следующее:

Реорганизация ветвления. Причиной конфликтов является то, что плагин выпуска изменяет версии магистрали и ветви после создания ветви Subversion. Чтобы обойти это, я

  1. поднимите версию багажника с помощью versions:set.
  2. используйте release:branch для создания ветви, но установите -DupdateWorkingCopyVersions=false, потому что я уже установил версию.

Это позволит избежать конфликтов слияния. Что остается, так это то, что всякий раз, когда я объединяю ветвь обратно со стволом, теперь я тоже объединяюсь с версией ветки. Снова versions:set на помощь.

...