SVN: Частичная реинтеграция филиала?

Question

Я использую SVN для контроля версий (с Eclipse / Subversive).

У нас есть ветка и ствол. Филиал для специализированной версии нашего проекта. Часто мы экспериментируем с некоторыми изменениями в ветке, а затем решаем, что эти изменения полезны и для основного проекта (магистрали). Но не ВСЕ изменения ветви необходимы в транке. Некоторым действительно нужно оставаться только в ветви, поскольку они подходят только для специальных функций этой ветви.

Я хотел бы иметь возможность выбирать файлы, которые будут реинтегрированы. В идеале я хотел бы, чтобы Synchronize-view от ветви к стволу ПЕРЕД выполнением слияния / реинтеграции, но это невозможно.

Как бы вы справились с этой ситуацией?

Answer 1

Я могу описать, как вы делаете это из Subclipse, а также как вы будете это делать с помощью командной строки.

Во-первых, вы не будете использовать merge --reintegrate.В идеале, все изменения, которые вы хотите объединить, были зафиксированы в одной или нескольких конкретных ревизиях в ветви.Затем вы просто объедините эти ревизии из ветви обратно в транк.Subclipse предоставляет простой пользовательский интерфейс для выбора ревизий, которые вы хотите объединить из ветви обратно в ствол, это опция «Объединить диапазон ревизий» в мастере слияния.Если ревизии содержали некоторые другие изменения, которые вам не нужны, вам придется отменить их до совершения слияния с транком.Это можно легко сделать из представления результатов слияния.

Давайте представим, что когда вы зафиксировали слияние со стволом, оно создало r100

Теперь вы хотите обновить ветку, чтобы r100 не слился назадк нему в следующий раз, когда вы синхронизируете его с транком.Поэтому для этого вы используете merge -c 100 --record-only в вашей ветке.В пользовательском интерфейсе Subclipse это опция «Блокировать редакции» в мастере слияния.Это обновляет информацию о слиянии в ветке, и вам просто нужно зафиксировать ее в ветке.Как только вы это сделаете, будущие синхронизирующие слияния с транком не будут пытаться слить эту ревизию обратно в ветвь.

Как только ветвь закончится, обычное слияние --reintegrate все равно будет работать нормально, и вы не сможетевозникли проблемы из-за изменений, которые вы уже слили из ветки.

Answer 2

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

http://martinfowler.com/bliki/FeatureBranch.html

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

Лучше всего кусать пули и реструктурировать код так, чтобы уникальный код для разных вариантов в основном помещался в разные файлы. Тогда просто есть несколько файлов, которые используют механизм внедрения зависимостей, или просто #if, в которых упоминаются оба варианта и настраиваются правильные наборы стратегий и фабрик и т. Д.

В качестве альтернативы, есть две команды. Когда необходимо внести изменения в оба варианта, сделайте их дважды. Это как минимум масштабируемо и предсказуемо.