Problem z przepływem Mercurial do Mercurial do Subversion Workflow

Question

Przeprowadzamy migrację z Subversion do Mercurial. Aby ułatwić migrację, tworzymy pośrednie repozytorium Mercurial, które jest klonem naszego repozytorium Subversion. Wszyscy programiści zostaną przełączeni na repozytorium Mercurial, a my będziemy okresowo przekazywać zmiany z pośredniego repozytorium Mercurial do istniejącego repozytorium Subversion. Po pewnym czasie po prostu zdezaktualizujemy repozytorium Subversion, a pośrednie repozytorium Mercurial stanie się nowym systemem zapisu.

Dev 1 Local --+--> Mercurial --+--> Subversion 
Dev 2 Local --+    + 
Dev 3 Local --+    + 
Dev 4 -------------------------+ 

ja testuje na to uwagę, ale wciąż działa w I problem gdy wciskam zmiany z mojego lokalnego repozytorium, do pośredniego Mercurial repozytorium, a następnie aż do naszego repozytorium.

alt text http://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/01.png

Na moim komputerze lokalnym mam changeset że jest zaangażowana i gotowy zostać przesunięta do naszego pośredniego Mercurial repozytorium. Tutaj można zobaczyć to rewizja # 2263 z hash 625 ...

alt text http://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/02.png

wciskam tylko ten changeset do zdalnego repozytorium.

alt text http://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/03.png

Jak dotąd, wszystko wygląda dobrze. Zestaw zmian został naciśnięty.

hg update 
1 files updated, 0 files merged, 0 files removed, 0 files unresolved 

Teraz przełączam się do zdalnego repozytorium i aktualizuję katalog roboczy.

hg push 
pushing to svn://... 
searching for changes 
[r3834] bmurphy: database namespace 
pulled 1 revisions 
saving bundle to /srv/hg/repository/.hg/strip-backup/62539f8df3b2-temp 
adding branch 
adding changesets 
adding manifests 
adding file changes 
added 1 changesets with 1 changes to 1 files 
rebase completed 

Następnie wprowadzam zmiany do Subversion, działa świetnie. W tym momencie zmiana jest w repozytorium Subversion i zwracam uwagę z powrotem na mojego klienta lokalnego.

alt text http://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/04.png

pociągnąć zmiany w moim komputerze lokalnym. Huh? Mam teraz dwa zestawy zmian. Mój oryginalny zestaw zmian pojawia się teraz jako oddział lokalny.

alt text http://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/05.png

Drugi changeset ma nowy numer wersji 2264, a nowy hash 10c1 ...

alt text http://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/06.png

Zresztą zaktualizować lokalnego repo do nowej wersji.

alt text http://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/07.png

Jestem teraz przełączane.

alt text http://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/08.png

Więc w końcu kliknij „określić i oznaczyć wychodzące Zestawienia zmian” i jak widać Mercurial nadal chce wypchnąć moje wcześniejsze Zestawienia zmian, mimo że już została przesunięta.

Najwyraźniej robię coś nie tak.

Nie mogę też scalić dwóch wersji.Jeśli scalę dwie wersje na moim komputerze lokalnym, otrzymam zatwierdzenie "scalania". Kiedy wysyłam to połączenie do pośredniego repozytorium Mercurial, nie mogę już przekazywać zmian do naszego repozytorium Subversion. Kończę z następującym problemem:

hg update 
0 files updated, 0 files merged, 0 files removed, 0 files unresolved 

hg push 
pushing to svn://... 
searching for changes 
abort: Sorry, can't find svn parent of a merge revision. 

i muszę wycofać scalenie, aby powrócić do stanu roboczego.

Czego mi brakuje?

Answer 1

Nie robisz nic złego, w rzeczywistości w twoim przypadku zachowanie, które widzisz, jest oczekiwane (jeśli nieco mylące dla nowego użytkownika Mercurial).

hgsubversion jest naprawdę dobre dla dwóch rzeczy:

1. korzystających Mercurial jako klienta Subversion, bez wymiany zmian poza svn
2. Konwersja repozytoriów Subversion do Mercurial

starasz używać go jako bardziej uogólnionej bramy, co jest o wiele trudniejszym problemem. Subversion ma bardzo surowy pogląd na świat i musimy w nim pracować. Prawda jest taka, że ​​wersja hash może być postrzegana jako ostateczna tylko przy użyciu hgsubversion po tym, jak rewizja została wycofana z Subversion. Tak więc, jeśli twoi programiści kiedykolwiek dzielą się zmianami bezpośrednio pomiędzy repozytoriami Mercurial, bez Subversion jako pośrednika, to nastąpi.

Podstawa do przebicia jest automatyczna i nieobowiązkowa z bardzo podstawowego powodu: Subversion wykonuje to przejęcie po naciśnięciu. Jeśli po pchnięciu wprowadziłeś zmiany bez pumeksu, Subversion zrobił to za ciebie, a jeśli się powiedzie (z głupio prostym algorytmem przerzucania), zaakceptuje zatwierdzenie bez żadnego wskazania, że ​​nastąpił rebase. Łączymy dwa różne modele.

Zaleciłabym natychmiastowe przeniesienie wszystkich na Mercurial - takie podejście hybrydowe tylko sprawi, że korzystanie z Mercurial będzie trudniejsze w krótkim czasie, niż jest to konieczne, i potencjalnie może wprowadzić użytkowników w błąd w DVCS.

Answer 2

Po pierwsze, pozwól mi powiedzieć, jaką przyjemność było przeczytać tak szczegółowe pytanie. :)

Problem występuje po wykonaniu hg push do repozytorium svn z pilota. Oto, że wyjście z przykładu:

hg push 
pushing to svn://... 
searching for changes 
[r3834] bmurphy: database namespace 
pulled 1 revisions 
saving bundle to /srv/hg/repository/.hg/strip-backup/62539f8df3b2-temp 
adding branch 
adding changesets 
adding manifests 
adding file changes 
added 1 changesets with 1 changes to 1 files 
rebase completed 

Nie jestem użytkownikiem HG-Subversion, ale że wyjście mówi, że w procesie robi push Żądana, to pociągnięcie zmiany z repo svn, znalezienie nowa wersja, a następnie wykonanie rebase Twojego zestawu zmian 10c1 po (potomku) nowo pobranej wersji. rebase command ma historię rozgałęziania i zamienia się w linearne historie, ale w ten sposób zmienia rodziców z zestawów zmian, które zmieniają swoje skróty, które wyglądają tak samo, jak to, co się dzieje z tobą.

Ponownie, nie użytkownik HG-Subversion, więc nie mogę powiedzieć, czy to ciągnąć/rebase jest zawsze powinno się zdarzyć i jak to miało działać, ale strona hgsubversion wiki mówi:

Ty może używać zwykłych poleceń Mercurial do pracy z tym repozytorium. Jeśli masz serię zatwierdzeń na danej branży i chcesz przenieść je do końcówkę tego oddziału, należy użyć HG rebase polecenie --svn podczas końcówki swojej pracy, a te będą Zestawienia zmian zostanie automatycznie utworzona nowa górna wersja .

co sprawia, że ​​dźwięk nie jest normalnie automatyczny.

Nie mogłem powiedzieć od twojego wstępu, czy nowe zestawy wciąż są tworzone w svn, czy też są tworzone tylko w trybie mercury?

Jeśli są one tworzone tylko w środowisku rtęci, jednym z nich byłoby utworzenie repozytorium svn-gateway na zdalnym systemie, a następnie przejście od tego miejsca i nigdy nie odciągnięcie od repozytorium z powrotem do rtęci. Wtedy zestawy zmian w tym repo będą miały różne pliki haszujące ze względu na rebase, ale nie powrócą do głównego zdalnego repo i systemów użytkowników końcowych.

Większą poprawką jest jednak ustalenie, dlaczego "hg push svn: // .. przesyła wszystkie wychodzące zestawy zmian". Odpowiedz, że jedno zachowanie się zatrzyma.

Answer 3

Używamy teraz polecenia graft, aby zrobić coś podobnego do tego. Skutecznie odtwarzamy każdy zestaw zmian, zanim go przepchniemy, aby uniknąć konieczności wprowadzania zmian scalania.

Naszym celem jest czysty udział w projekcie wykorzystującym subversion.

• Utwórz gałąź podwersji dla wszystkich zmian. Zdobądź to w Mercurial.
  $ cd [svn-checkout] ; svn cp trunk branches/hg-bridge
  $ cd [hgsubversion bridge] ; hg pull ; hg update hg-bridge

• Sprawdź swoje lokalne repo do nowych zmian
  $ hg in [repo] # shows <rev> IDs you can use later

• Pociągnij zmiany, które chcesz dostać się do svn z lokalnego repo
  $ hg pull [repo]

• Prześlij wszystkie zmiany, które chcesz wesprzeć:
  $ hg graft [rev] [rev] # rev could be 645 or b7a92bbb0e0b. Best use the second>. Musisz określić każdy rev indywidualnie,
  , ale możesz zaszczepić kilka obrotów w jednym poleceniu.

• Sprawdź, co można wcisnąć:
  $ hg outgoing

• popchnąć zmiany:
  $ hg push
  Ten potęga pokazać kilka niepowiązanych ciągnięte rewizje
  i powinny pokazać swoje nowe wersje jak ciągnięty,
  wraz ze ścieżkami do tworzenia kopii zapasowych pakietów (które nie powinny być potrzebne). (Komentarz można również użyć nder the GPLv2 lub nowszy)