Как объединить выбранные вишней ревизии между функциональными ветвями и стволом

Question

У меня есть две ветви функций, полученные из магистрали, обе из которых связаны с большой реорганизацией кода в разных модулях, Feature-A и Feature-B.Оба синхронизируются со стволом;магистраль должна быть стабильной.

На полпути, работая над Feature-B, я понимаю, что изменение в разделяемой библиотеке, недавно реализованной на Feature-A, значительно выиграет от Feature-B.Я пока не хочу помещать это изменение в ствол, и я не могу полностью объединить ветви, потому что остальная часть кода в Feature-A нестабильна.

Так что слияние между ветвями, выбор вишниревизии от A до B, чтобы объединить только эту функцию:

svn merge -r 1786: 1795 ^ / proj / branch / Feature-A.

Я не могу понять, попаду ли я впроблемы позже, когда я реинтегрирую ветки.Я ожидаю, что Feature-B будет закончен намного раньше, чем Feature-A.В этот момент наша обычная процедура состояла бы в том, чтобы повторно интегрировать функцию B в транк, а затем объединить транк в функцию A, чтобы синхронизировать их.Мне сложно заранее выяснить, не вызовет ли это конфликт, поскольку А был объединен с В, и теперь эти изменения возвращаются обратно, но окольным путем, через магистраль.

svn book упоминаетчто после слияния ветки с внешней ветвью требуется дополнительное слияние с --record-only, если я хочу снова работать с веткой.Я подозреваю, что мне может понадобиться что-то подобное в этой ситуации, но я не могу работать, если это необходимо.

Answer 1

Это действительно вызовет у вас проблемы.

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

Объединение --record-only используется, чтобы заблокировать повторное объединение определенных ревизий, чтобы сохранить ветвь объекта после реинтеграции.Таким образом, если вы реинтегрируете B в магистраль, создавая ревизию 100, то вы - - запись только для слияния ствола ревизия 100 обратно в B, это означает, что когда вы делаете синхронизированное слияние в B из транка (svn merge ^ / Project1 / trunk) ревизия 100будет пропущен и не возвращен обратно в B. Это позволяет избежать потенциального конфликта и позволяет продолжить использование ветви компонента и выполнить повторную синхронизацию с транком после реинтеграции.

К сожалению, я не думаю, что --record-onlyСлияние может помочь вам избежать конфликта в вашей ситуации, поскольку слияние при реинтеграции не проверяет отдельные ревизии в ветви, подлежащей слиянию, а просто анализирует текущее состояние ветви и магистрали и применяет ее к работающей магистрали.копия.

Answer 2

Лично я не использую --reintegrate с долгосрочными функциональными ветвями.

В вашем случае вы можете слить ветку Feature-B обратно в магистраль, а затем, прежде чем слить Feature-B обратно втранк, выполните --record-only до проблемной ревизии:

Предположим, что команда:

svn merge -r 1786:1795 ^/proj/branches/Feature-A .

создала ревизию 2000 (в ветви Feature-B).

Тогдаперед слиянием Feature-B обратно в транк вы должны сделать:

svn merge -c2000 --record-only ^/proj/branches/Feature-B .

Последний шаг - полное слияние ветки Feature-B с транком:

svn merge -r <begin>:<end> ^/proj/branches/Feature-B .