Объединить две кассы на базаре

Question

Я только начинаю работать с bazaar и обнаружил, что функция оформления заказа является наиболее полезной для моей работы, а именно: я могу использовать «мастер-копию», выполнить некоторую разработку, а затем зафиксировать свои изменения в новый каталог.Затем обновляется «основная копия».

Но что, если я работаю (например) над двумя проектами, изменяя разные части кода?Сказать:

~/master                - master copy
bzr co master ./gui
bzr co master ./engine

Итак, я делаю вещи, связанные с графическим интерфейсом, в каталоге ./gui и скрытые вещи в ./engine.Как мне зафиксировать изменения?Если я сначала фиксирую графический интерфейс, а затем движок, я думаю, любые конфликты будут отмечены в движке?

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

Чтобы немного усложнить ситуацию, как насчет того, чтобы сделать это:

bzr branch gui ./mouse

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

bzr branch gui ./keyboard

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

Надеюсь, понятно, чего я пытаюсь достичь!Спасибо заранее за ваше время.

Answer 1

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

Однако похоже, что вы хотите, чтобы отдельные разработчики работали над «gui» и «движком», или вы просто хотите сохранить разрешение конфликтов до завершения разработки в обеих ветвях.В этом случае вам, вероятно, следует создать их как независимые ветки с помощью «bzr Branch».Каждая ветка может использовать локальные коммиты и не беспокоиться о конфликтах друг с другом.Затем, когда придет время объединиться, вы можете сделать это одним из трех способов, каждый из которых дает один и тот же конечный результат:

1.Объедините одну ветку с другой, а затем поднимите ее вверх до мастера:

cd gui
bzr merge ../engine
# manually fix any conflicts
bzr commit
bzr push #back up to main

Недостатком описанного выше метода является то, что ваша ветка «gui» теперь содержит изменения «движка».Это нормально, если вы собираетесь выбросить обе ветви, как только они будут возвращены в основную линию.Но если вы хотите сохранить ветки длиннее, вы можете:

2.Слияние с основной линией:

cd master
bzr merge ../gui
bzr commit
bzr merge ../engine
# manually fix conflicts
bzr commit

Положительным моментом является то, что у вас по-прежнему есть «gui» и «engine» как отдельные ветки, но вам пришлось зафиксировать одну из них для освоения, прежде чем вы были уверены, что они обе будут работать вместе.Итак, вы действительно, вероятно, хотите:

3.Создайте ветку слияния:

bzr branch ~/master gui-engine-merge
cd gui-engine-merge
bzr merge ../gui
bzr commit
bzr merge ../engine
# manually fix conflicts
bzr commit
bzr push ~/master
# since this branch was only for merging, you don't need it anymore:
cd ..
rm -r gui-engine-merge

Answer 2

Да, bzr должен запретить вам проверять изменения из репозитория движка, если он обнаружит конфликты.Обычно вы сначала делаете «bzr up» непосредственно перед регистрацией, а затем проверяете, что ваши вещи хорошо работают с другими.

Что касается второй части вашего вопроса, касающейся ветвей мыши/клавиатуры, то я обычно это делаю именно так.Просто перейдите в каталог графического интерфейса, а затем выполните:

bzr merge ../mouse

После слияния изменений вы можете зафиксировать их из каталога gui, и он отправит набор изменений в «главный» каталог.

Обратите внимание, что я вряд ли эксперт по bzr, но именно так я имел дело с репозиториями SVN.