2010-01-11 5 views
17

Używam bzr do bardzo prostego zadania: uzyskanie wersji rozwojowej GNU Emacs. Po początkowej bzr branch, chciałbym, aby moja lokalna wersja była aktualna. Czytałem o dokumentacji pod numerami bzr pull i bzr merge, ale nie mogłem tego zrozumieć. Próbowałem przez kilka dni bzr merge i odkryłem, że bzr merge często powodowało nierozwiązywalne konflikty. Zwróć uwagę, że nie wprowadziłem żadnych lokalnych zmian. Czy zalecany jest bzr pull?bzr pull vs bzr merge

Edycja 1 (dodawane schemat skradziony Chris Conway):

remote: A --> B --> C --> D 
     \     \ 
     (branch)   (merge) 
      \     \ 
local:  \--> A (no change) \--> why conflicts? 

I rozumie git i darcs, ale nie ma wiedzy o BZR. Analogie do git lub darcs bardzo pomogą.

EDIT 2: Czy update ma działać tylko z checkout? Wykonanie update w branch wydaje się nic nie robić.

+1

jestem usunięcie znacznika emacs i dodanie wersji nad sobą, ponieważ jest to bardziej z tego samego Emacsa. –

Odpowiedz

35

Należy pamiętać, że nie wprowadziłem żadnych lokalnych zmian . Czy zalecany jest sposób bzr pull ?

Tak, brzmi jak bzr pull jest odpowiednią komendą do użytku. pull pobiera zdalną gałąź źródłową i kopiuje wszelkie zmiany z niej do lokalnego folderu docelowego w starszej wersji. (Używam „zdalny” i „lokalne” tutaj oznacza „źródło” i „cel”. Jakieś dwa oddziały zrobi, nawet dwa lokalne oddziały.)

remote: A --> B --> C --> D 
     \     \ 
     (branch)   (pull) 
      \     \ 
local:  \--> A (no change) \--> D 

pull działa tylko wtedy, gdy przystań dwa oddziały” t rozbieżności, tzn. jeśli rewizja celu jest starą wersją źródła. push to operacja odwrotna: kopiuje zmiany w oddziale lokalnym do oddziału zdalnego w starszej wersji.

remote: A  (no change)  --> C 
     \     /
     (branch)    (push) 
      \    /
local:  \--> A --> B --> C 

A merge jest używany, gdy chcesz skopiować zmiany do lokalnego oddziału, który odbiegał od zdalnego oddziału.

remote: A --> B --> C --> D 
     \     \ 
     (branch)   (merge) 
      \     \ 
local:  \--> A --> X --> Y --> Z 

Tutaj Z obejmuje wszystkie zmiany od D i zmian z Y. A pull nie jest w tym przypadku możliwe. Zauważ, że musisz commit po merge, aby zapisać nową scaloną wersję, podczas gdy pull automatycznie przenosi gałąź do zapisanego punktu wersji.

A checkout pozwala na użycie bzr w trybie podobnym do CVS/SVN: lokalny oddział zostanie "dołączony" do odległego oddziału; commit s zostanie automatycznie zmieniony na push; jeśli gałąź zdalna rozdzieliła się, zatwierdzanie zakończy się niepowodzeniem; update to tylko merge z "dołączonej" gałęzi zdalnej.

+0

Ładne ascii, dzięki. Co jest dla mnie niejasne, dlaczego "scalanie" powoduje konflikty, nawet jeśli nie ma lokalnych zmian? –

+2

Czy pojawiają się konflikty nawet podczas pierwszego "scalania" lub dopiero po "scaleniu" więcej niż raz? Czy "commit" po każdym "scaleniu"? Algorytm łączenia jest skomplikowany, a to, co może i nie może rozwiązać bez konfliktów, jest często zaskakujące. –

+2

Po "scaleniu" więcej niż raz. Nie "popełniłem" po każdym "scaleniu". To wszystko ma teraz sens. –

4

Scalenie służy do łączenia dwóch różnych gałęzi, a nie kopii (lokalnych i zdalnych). Użyj pull.

1

$ bzr help pull

Cel: Włączenie tej gałęzi w lustro innego oddziału.

--overwrite Ignoruj ​​różnice między gałęziami i nadpisuj bezwarunkowo.

Jeśli chcesz zastąpić lokalne zmiany i chcesz, aby Twój oddział pasował do oddziału zdalnego, użyj polecenia pull --overwrite. To zadziała nawet , jeśli dwie gałęzie rozdzieliły się.

więc można użyć:

$ bzr pull --overwrite