Советы по ручному слиянию расходящегося кода

Question

Я довольно привык использовать svn для ветвления и слияния, обычно это работает нормально. Однако один компонент работал в двух ветвях и в основном использовал его в разных направлениях, поэтому автоматическое объединение не будет работать, и использование вне сравнения показывает, что файлы в основном отличаются.

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

Мне хочется сказать бизнесу, что это просто невозможно. Я могу видеть, как это расстраивает их, так как у них есть модуль + функция A работает и модуль + функция B работает, но модуль + функция A + функция B просто не имеет смысла. Например, функция A может удалить то, что было ключевым компонентом в функции B.

Есть ли способ попытаться объединить такой код? Или модуль + A + B действительно модуль + C?

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

Answer 1

То, о чем вы говорите, - это попытка перебазировать одну из веток. Это поддерживается в некоторых DVCS , но я не знаю никакой поддержки такого рода вещам в SVN.

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

Как избежать этого в будущем? Частая интеграция .

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

Вот почему проекты с открытым исходным кодом часто выступают против огромных патчей, они потрясающе быстро устаревают, и у кого-то действительно нет времени, чтобы их правильно просмотреть. С другой стороны, если вы берете тот же вклад и разбиваете его на несколько мелких усваиваемых частей, которые стоят отдельно, ваш вклад, скорее всего, будет A) принят и B) рассмотрен должным образом, чтобы не привести к бесконечный поток дефектов.

Answer 2

Возьмите один файл, скажем, src1.c. Вы можете построить диаграмму ромба, описывающую слияние следующим образом:

   Original src1.c
        /       \
       /         \
      /           \
   b1 src1.c     b2 src1.c
      \            /
       \          /
        \        /
         \      /
        merged src1.c

Где b1 означает первую версию ветви, а b2 означает вторую версию ветви. Вы можете сравнить параллельные различия (скажем, между объединенным источником и версией b2 и b1 и оригиналом). Это может помочь.