Безопасно ли сливаться между ветвями функций в SVN?

Если два разработчика каждый создают ветвь функции из магистрали, безопасно ли им "синхронизировать слияние" между их ветвями функций, а также с внешней стороны, а затем все же иметь возможность реинтегрировать каждую ветвь элемента в магистраль без проблем?

Под "sync merge" я подразумеваю команду формы "svn merge ^/Project1/trunk" и "svn merge ^/Project1/branch/other-feature-branch", где свойство svn: mergeinfo будет отслеживать что было объединено уже из каждого местоположения.

Причина, по которой я спрашиваю, это то, что я читал документацию в нескольких местах, которые предполагают, что переключение в те же ревизии на ветку вызовет проблемы с конфликтом (хотя я не вижу нигде, где это объясняется, почему это должно быть случай). Если это так, описанный выше сценарий должен быть проблематичным, потому что каждая ветвь функции будет синхронизироваться с соединительной линией, а также с другой ветвью функций, поэтому любые изменения, сделанные в соединительной линии, получаются как напрямую, так и синхронизируясь с соединительной линии, а также при синхронизации с другая ветвь функции (которая, возможно, уже подняла те же изменения соединительных линий).

Однако при тестировании, которое я сделал, это работает отлично, но я хотел бы получить некоторое экспертное подтверждение, прежде чем рекомендовать это как рабочий процесс для нашей команды.

@nosid: ответ на nosid в этом редактировании, потому что смешной лимит символов на SO предотвращает комментарий из 4 предложений. Что это за Twitter?

Я прочитал документацию. Проблема заключается в том, что он описывает очень простой сценарий, в котором одновременно обрабатывается только одна дестабилизирующая функция, и где дестабилизирующая работа выполняется в ветки функции, а вся другая работа выполняется в соединительной линии. В этом сценарии тривиально держать ветвь функции синхронно со стволом.

Однако в более реалистичном сценарии продукт может легко иметь сразу несколько серьезных дестабилизирующих работ. В чем же заключается процесс синхронизации этих частей работы таким образом, чтобы они могли синхронизировать по требованию с багажником и друг с другом, но не нарушая навязанных им изменений?

+3
источник поделиться
3 ответа

Это не так, в Subversion должны использоваться ветки функций. Тест с простым примером показывает, что этот подход вызовет проблемы позже. Выполните следующие шаги:

  • Создайте новый репозиторий.
  • Создание и фиксация исходной структуры (соединительной линии, ветвей, тегов).
  • Создайте и зафиксируйте две новые ветки (пустой) соединительной линии с помощью svn cp -m 'new branch' ^/trunk ^/branches/a и соответствующую команду для ^/branches/b.
  • Добавить и зафиксировать новый файл в ветке b.
  • Объединить изменения из ветки b в ветвь a с помощью svn merge ^/branches/b. Я не внес никаких изменений в багажник, поэтому нет ничего, что можно было бы объединить.
  • Восстановите и зафиксируйте ветвь a на внешней линии с помощью svn merge --reintegrate ^/branches/a.
  • Слияние изменений с соединительной линии на ветку b с помощью svn merge ^/trunk.
  • Теперь вы увидите конфликт дерева в файле, который вы добавили ранее.

Документация Subversion подробно описывает рекомендуемое использование ветвей функций. См. Следующую ссылку: Филиалы функций. Функциональная ветвь обычно создается из ствола. Вы вносите свои изменения в ветки функции и непрерывно объединяете изменения с соединительной линии в свою ветку функций (с помощью svn merge ^/trunk). И как только вы закончите свою работу, вы реинтегрируете ветку в багажник (с помощью svn merge --reintegrate ^/branches/name). После реинтеграции ветвь функции устарела и больше не должна использоваться.

+4
источник

Если вы будете синхронизировать обе ветки признаков друг с другом, то какая точка имеет два?

Они будут, по сути, одинаковыми.

0
источник

Здесь я беру на себя вопрос ОП. Вы можете заметить некоторые параллели с этапами тестирования, предложенными другими источниками для определения ответа на вопрос, но я пришел к другому выводу.

Здесь мой репрограммирование script:

#----------------------------------------------------------------------
# Test whether merging between feature branches in SVN results in
# tree conflicts, as claimed elsewhere:
#   http://stackoverflow.com/questions/10015249
#----------------------------------------------------------------------
export REPO=file:///tmp/merge-test/repo

#----------------------------------------------------------------------
# Create a new repository.
#----------------------------------------------------------------------
echo Creating a new repository ...
cd /tmp
rm -rf merge-test
mkdir merge-test
cd merge-test
svnadmin create repo

#----------------------------------------------------------------------
# Create and commit the initial structure (trunk, branches, tags).
#----------------------------------------------------------------------
echo Creating initial structure ...
svn mkdir $REPO/trunk -m "Initializing trunk"
svn mkdir $REPO/branches -m "Initializing branches"
svn mkdir $REPO/tags -m "Initializing tags"

#----------------------------------------------------------------------
# Create and commit two new branches of the (empty) trunk.
#----------------------------------------------------------------------
echo Creating two new branches of the empty trunk ...
svn cp $REPO/trunk $REPO/branches/a -m "branch a"
svn cp $REPO/trunk $REPO/branches/b -m "branch b"
svn co $REPO/trunk
svn co $REPO/branches/a
svn co $REPO/branches/b

#----------------------------------------------------------------------
# Add and commit a new file on branch b.
#----------------------------------------------------------------------
echo Adding and committing a new file on branch b ...
cd b
echo testing > foo
svn add foo
svn ci -m "committing new file"

#----------------------------------------------------------------------
# Merge the changes from branch b to branch a.
#----------------------------------------------------------------------
echo Merging the changes from branch b to branch a ...
cd ../a
svn merge ^/branches/b
svn commit -m "merged b into a"

#----------------------------------------------------------------------
# Reintegrate and commit branch a on the trunk.
#----------------------------------------------------------------------
echo Reintegrating and committing branch a back to the trunk ...
cd ../trunk
svn merge --reintegrate ^/branches/a
svn ci -m "merged a back into trunk"

#----------------------------------------------------------------------
# Merge the changes from the trunk to branch b.
#----------------------------------------------------------------------
echo Merging the changes from the trunk to branch b ...
cd ../b
svn up
svn merge ^/trunk
svn ci -m "refreshing b from trunk"

#----------------------------------------------------------------------
# Look for a tree conflict on the file added earlier.
#----------------------------------------------------------------------
echo Looking for tree conflicts for the file added earlier ...
svn status

Нет результата из последней (svn status) команды, которая предположительно означает отсутствие конфликтов дерева. Насколько я могу судить, в http://svnbook.red-bean.com/ нет явного выражения, указывающего на то, что слияние между ветвями вызовет проблемы (за пределами обычных конфликтов, может возникнуть слияние, включая слияние между ветвью и магистралью). Если у кого-то есть доказательства того, что слияние межотраслевых соединений является более проблематичным, чем слияние в целом, мне было бы очень интересно изучить эти доказательства. До тех пор я склонен советовать ОП, что на практике нет ничего опасного.

0
источник

Посмотрите другие вопросы по метке или Задайте вопрос