GIT łączenie gałęzi svn kończy się niepowodzeniem tworzenia pliku BASE - git, svn, branch, clone

Pracuję nad projektem, który używa svn dla CVS i około 5-6 miesięcy temu rozwinęliśmy gałąź wersji_1__1__1_1 z pnia. Teraz muszę je połączyć.

Aby zmniejszyć obciążenie svn, chciałem spróbować git do scalenia, więc postępowałem zgodnie z instrukcjami: http://blog.wuwon.id.au/2010/09/painless-merge-conflict-resolution-in.html

W końcu używam następujących poleceń:

git svn clone -s hxxp://svn/repo/project project (this takes avout 20min for +30k commmits)
git checkout -b version_1.9.1 remotes/version_1_9_1
git checkout -b the_trunk trunk
git merge version_1.9.1

ale kiedy wykonuję „git scaletool” dla, powiedzmy pliku web.xml, meld otwiera okna dialogowe dla LOCAL i REMOTE, ale brakuje pliku BASE.

Gdy okna dialogowe łączenia są nadal otwarte, sprawdź, które pliki tam są, i uzyskaj następującą listę:

web.xml
web.xml.BACKUP.12480.xml
web.xml.LOCAL.12480.xml
web.xml.REMOTE.12480.xml

Tak więc, dla mojego zrozumienia, powinien istnieć również plik o nazwie web.xml.BASE.12480.xml, ale brakuje go.

Wynik jest taki sam bez względu na to, czy diff3 jest aktywowany czy dezaktywowany.

Doprowadziło mnie to do wniosku, że coś jest nie tak z klonowaniem ... Więc wykonałem następujące polecenia w czystym katalogu:

git svn clone -s hxxp://svn/repo/project project
gitk
git checkout -b version_1.9.1 remotes/version_1_9_1
gitk
git checkout -b the_trunk trunk
gitk

(Btw. Robię to na Ubuntu 11.04)

Za każdym razem, gdy uruchamiam gitk, widzę płaską „hierarchię”,gdzie wszystkie svn zatwierdzenia są po drugim. Więc jeśli dobrze to rozumiem, w „klonie git svn” jest coś nie tak, ponieważ git nie może znaleźć wspólnego przodka dla wersji trunk i branch_1.9.1.

Czy ktoś może wskazać mi właściwy kierunek w tej sprawie?

Dziękuje za przeczytanie.

Odpowiedzi:

0 dla odpowiedzi № 1

Problem dotyczył gałęzi svn. Został rozwidlony z bagażnika, aby nie było między nimi połączenia.

Aby sprawdzić, czy użyłem:

$ git svn clone -s hxxp://svn/repo/project project
$ git checkout -b the_trunk remotes/trunk
$ git checkout -b version_1.9.1 remotes/version_1_9_1
$ git branch
master
the_trunk
version_1.9.1
$ git merge-base the_trunk version_1.9.1

polecenie merge-base nie wydrukowało niczego, co wskazuje, że te dwie gałęzie nie miały związku.

Myślę, że istnieje wiele sposobów rozwiązania tego problemu. Ponieważ jestem bardzo nowy z git, nie mogłem wymyślić żadnego sprytnego sposobu wykorzystania potencjału gits, więc wybrałem rodzaj brutalnej siły:

1. Szukałem ostatniego zatwierdzenia w bagażniku, z którego rozwidlono wersję_1__1_9_1.
2. od tego momentu utworzyłem nową gałąź git
3. zastąpił całą treść z tej nowej gałęzi treścią wersja_1__1__1_1
4. połączył go z pniem
5. bawił się konfliktami scalania (poważnie, było to o wiele łatwiejsze niż to, co zaoferowałby svn).

Poniżej znajdują się polecenia wykonania 5 kroków powyżej:

$ gitk <= to find git revision id of forked commit, lets say its 97bc8071-70e0-0310-82d1-dfb2d704a1b1
$ git checkout the_trunk
$ git branch fake_version_1.9.1 97bc8071-70e0-0310-82d1-dfb2d704a1b1
$ git checkout version_1.9.1
$ mkdir ../temp
$ cp -r projectfiles ../temp     <= remember not to copy .git directory
$ git checkout fake_version_1.9.1
$ rm -r projectfiles
$ cp -r ../temp/* .
$ git commit -a
$ git checkout the_trunk
$ git merge fake_version_1.9.1
$ git mergetool     <= google "git mergetool" for instruction to setup tool for conflicts, I used p4merge
$ git commit -a
$ git svn dcommit

Ogólnie byłem bardzo zadowolony z tego połączenia. Trochę czasu zajęło ustalenie, że te dwie gałęzie nie były ze sobą połączone, co uniemożliwiło git merge wygenerowanie pliku .BASE. Generowanie fałszywej gałęzi pozwoliło gitowi wygenerować plik .BASE, co znacznie ułatwiło scalanie: Całkowita liczba zmienionych plików: 390 plików

Scal konflikty bez fałszywej gałęzi: 220 plików vs. Scal konflikty z fałszywą gałęzią: 68 plików

Ponadto, po przejściu całej fuzji, zacząłem się zastanawiać, czy połączenie bez fałszywej gałęzi byłoby w ogóle możliwe - przynajmniej w rozsądnych ramach czasowych.

Dziękuje za przeczytanie.

---