Mesclar dois checkouts em bazar

Question

Eu estou apenas começando com bazar, e eu descobri que o recurso de check-out é o mais útil para o trabalho de maneira que eu - ou seja, eu posso c / o de uma "cópia master", fazer algum desenvolvimento e, em seguida, cometer minhas mudanças no novo diretório. Isso, então, atualiza a "cópia mestra".

Mas o que se eu estou trabalhando em (por exemplo) dois projetos, mudando diferentes partes do código? Diga:

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

Então, eu estou fazendo coisas gui-relacionado no diretório ./gui e sob o capô o material em ./engine. Como devo comprometer minhas alterações? Se eu cometer gui primeiro, depois do motor, eu acho que qualquer conflito será sinalizado no motor?

Existe uma maneira de gui merge e motor, e, em seguida, fazer apenas uma se comprometer com a cópia mestre?

Para tornar as coisas um pouco mais complicadas, como sobre se eu fizer isso:

bzr branch gui ./mouse

Agora eu talvez eu estive trabalhando em rato, mas também em gui. Se eu quiser mesclar o código da GUI e rato, e depois comprometer-se mestre, qual é a melhor maneira de gerenciar isso? Ou, na verdade, se eu também:

bzr branch gui ./keyboard

Se eu mudei alterado gui, teclado e mouse, devo hierarquicamente fundir -? Ie mouse + teclado, em seguida, mesclar isso com gui, em seguida, cometer gui de dominar

Espero que seja claro o que eu estou tentando alcançar! Agradecemos antecipadamente pelo seu tempo.

Answer 1

Se você tem dois checkouts, a qualquer hora que você confirmar as alterações a um, você primeiro terá que puxar para baixo quaisquer alterações em relação à outra, potencialmente ter que resolver conflitos em cada etapa. Esta é geralmente uma boa idéia, já que é mais fácil de resolver conflitos ao longo do tempo e se certificar que seu código não divergem muito.

No entanto, parece que você quer ter os desenvolvedores independentes que trabalham em "gui" e "motor", ou você só quer salvar a sua resolução de conflitos até o desenvolvimento em ambos os ramos foi concluída. Neste caso, você provavelmente deve criá-los como ramos independentes com "ramo bzr". Cada ramo pode usar commits locais e não se preocupar com conflitos uns com os outros. Então, quando chega a hora de mesclar você pode fazê-lo uma das 3 maneiras, todos os quais recebem o mesmo resultado final:

1. Mesclar um ramo para o outro, em seguida, empurre-o para mestre:

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

A desvantagem do método acima é que o seu ramo "gui" tem agora as mudanças "motor" na mesma. Que é bom se você estiver indo para jogar fora ambos os ramos, uma vez que está empurrado para trás na linha principal. Mas se você quiser manter os ramos mais tempo, você pode:

2. Fundir-se na linha principal:

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

Isto tem a vantagem de que você ainda tem "gui" e "motor" como ramos separados, mas você já teve a cometer um para mestre antes você tinha certeza que iriam ambos trabalham juntos. Então, você realmente quer provavelmente:

3. Criar um ramo fusão:

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

Yes, bzr should prevent you from checking in changes from the engine repo if it detects conflicts. Normally, you first do "bzr up" just prior to check-in and then make sure your stuff plays nice with others.

As for the second part of your question, dealing with mouse/keyboard branches, this is how I would normally do it. Simply cd into the gui dir, and then do:

bzr merge ../mouse

After merging the changes, you can then commit from the gui directory and it will send the changeset to the "master" directory.

Note that I'm hardly a bzr expert, but this is the way I've been dealing with SVN repos.