Статьи

Тестирование Ограничений Слияния Subversion

Июль 19, 2017

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

Эта статья не об этом как таковом, но о возможностях слияния Subversion 1.9.2. Возьмите только правую нижнюю часть этой диаграммы /baz/UATи /baz/PROD. Я хочу слиться назад и вперед между двумя. Скажем, «baz» — это человек, и я запустил для них среду UAT и PROD. Внутри только один файл, и для наших целей я назвал его testfile.txt.

Я сделал репозиторий Github, в котором есть несколько скриптов bash со вкусом Mac, чтобы показать ограничение слияния, о котором я говорю: github.com/paul-hammant/subversion_testing . Убедитесь, что вы установили Subversion 1.9.2 (еще не выпущен, но есть инструкции по доморощению, если вы нажмете выше).

Test One — объединение в одну сторону — все хорошо

Здесь мы собирались проверить слияние некоторых отдельных коммитов, вышедших из строя, из одной ветви в другую.

Для того, чтобы запустить эти:

./reset.sh 
./server.sh 
./test_of_out_order_merges_from_one_branch_to_another.sh

Обязательно прочитайте тестовый скрипт. Предполагается объединить кучу изменений из «одного» в «два», но не в порядке.

Файл one / testfile.txt начинается так:

a

b

c

d

e

И изменения в пять однострочных коммитов:

a aa

b bbb

c cccc

d ddddd

e eeeeee

Вторая ветвь ‘two’ создается из начальной psition, и те же пять коммитов выбираются из ветки ‘one’ в эту новую, но не в порядке, чтобы попытаться запутать отслеживание слияний Subversion.

Обратите внимание, что эти строки ближе к концу вывода третьего скрипта bash:

Mergeinfo, after merge of all the individual commits (out of order)
/one:3-7
Mergeinfo, after merge of all the remaining commits (whatever that means)
/one:2-12

Subversion — это странно — во втором из них вообще нечего было объединять (с точки зрения коммитов), но он хочет сделать дополнительный коммит «mergeinfo», как показывает изменяющийся диапазон. В частности, mergeinfo изменяется с «/ one: 3-7» на «/ one: 2-12». Тем не менее, будь то «/ one: 3-7» или «/ one: 2-12», это значительное упрощение (и ретроактивное приведение в порядок) середины серии слияний, где было указано «/ one: 3,5,7 ”(первые три из пяти слияния чекриков).

Тест Два — Слияние назад — Есть Ошибка

Здесь мы собираемся проверить слияние некоторых отдельных коммитов не по порядку со второй ветви на обратную к первой.

Для того, чтобы запустить эти:

./reset.sh 
./server.sh 
./test_of_out_order_merges_back_the_original_branch.sh

Это запускает первый скрипт bash в режиме без вывода сообщений — создает ветки ‘one’ и ‘two’, а затем выполняет еще пять однострочных коммитов, оставляя документ в ‘two’ следующим образом:

a !! aa

b !! bbb

c !! cccc

d !! ddddd

e !! eeeeee

Затем каждый из этих коммитов сливается обратно в «один», но снова выходит из строя. Вот последний фрагмент вывода команды, где он неожиданно преграждается:

Mergeinfo, after merge of all the individual commits (out of order)
/two:14-18
Contents of testfile.txt on branch 'one':
a !! aa

b !! bbb

c !! cccc

d !! ddddd

e !! eeeeee

Contents of testfile.txt on branch 'two' (they are the same, as a result of merges):
a !! aa

b !! bbb

c !! cccc

d !! ddddd

e !! eeeeee

Attempt redundant merge of branch two into branch one (individual commits are merged already, and files at HEAD revision are idential):
--- Merging r2 through r13 into 'one':
C    one/testfile.txt
--- Recording mergeinfo for merge of r2 through r13 into 'one':
 U   one
Summary of conflicts:
  Text conflicts: 1
Conflict discovered in file 'one/testfile.txt'.
Select: (p) postpone, (df) show diff, (e) edit file, (m) merge,
        (mc) my side of conflict, (tc) their side of conflict,
        (s) show all options:

Это не имеет смысла. Файлы идентичны — объединять нечего. Все индивидуальные изменения были объединены в стиле вишневого пика, так почему же возникает конфликт слияния?

Обработка реинтеграции изменилась в Subversion 1.8, но та же ошибка показана в Subversion 1.6 и 1.7 (старый добрый домашний напиток). Вы можете сделать так, чтобы это не мешало, добавив разумное --record-onlyслияние, которое должно быть неактивным. Вы не можете сказать, хотя, и это не должно быть неразумным спросить механизм слияния, есть ли какие-либо ожидающие слияния или нет.

Вот что svn-diff говорит в точке конфликта слияния (если вместо попытки слияния):

Index: .
===================================================================
--- .(.../two)(revision 23)
+++ .(.../one)(revision 23)

Property changes on: .
___________________________________________________________________
Modified: svn:mergeinfo
## -0,1 +0,1 ##
   Reverse-merged /one:r2-12
   Merged /two:r14-18

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

34
Share: