2012-12-19 14 views
6

Mam repozytorium git svn. Mam tu wiele oddziałów wydań. Przygotowywałem nowe wydanie i jako część tego doszedłem do wniosku, że zrobię "git rebase" z poprzedniej wersji, aby przeciągnąć wszelkie zmiany, które nie zostały połączone."git rebase <branch>" na git svn repo zmienił cel zdalnego śledzenia?

Więc założyłem moje gałęzie ...

git branch new_release remotes/svn-branches/new_release 
git branch old_release remotes/svn-branches/old_release 

A potem zrobiłem rebase ...

git checkout new_release 
git rebase old_release 
# watch it pull a bunch of commits 
git svn dcommit 
    Committing to https://svn.mysvn.net/repo/releases/old_release ... 

Po zrobiłem "svn dcommit" I prawie crapped moje spodnie. To był mój stary oddział w Subversion!

Dlaczego zdalne śledzenie gałęzi zmieniło się w wyniku wykonania rebelii?

Jak naprawić sytuację, w której się znalazłem?

EDIT: Dobra, do poruszania się na zewnątrz Wierzę, że mogę wykonać następujące czynności: http://svnbook.red-bean.com/en/1.5/svn.branchmerge.basicmerging.html#svn.branchmerge.basicmerging.undo

Ponieważ istnieje tylko garstka zatwierdzeń, które były na oddziale new_release że wyciągali do old_release mogę przywrócić je ręcznie na repozytorium SVN. Wciąż jestem zdezorientowany tym, co się tutaj wydarzyło.

EDITx2: Tak, oto kilka kroków, aby zweryfikować.

  1. Skonfiguruj dwa git oddziałów śledzenia zdalnie do oddziałów SVN
  2. sprawdzić jeden z oddziałów
  3. Run git svn info i obserwować punkty URL do właściwej lokalizacji w SVN
  4. Run git rebase <other_branch>
  5. Run git svn info ponownie i obserwuj adres URL zmieniony tak, aby wskazywał na inną lokalizację oddziału w SVN

Odpowiedz

7

Wygląda na to, że popełniłeś błąd podczas pracy z git-svn.

Nie ma czegoś takiego jak "odgałęzienia śledzenia" w git-svn. Zawsze określa adres URL gałęzi do dcommit na historię pierwszego nadrzędnego, dopóki nie zostanie wykonane pierwsze zatwierdzenie z sygnaturą "git-svn-id:". Adres URL znajdujący się w pobliżu tego podpisu to adres URL, w którym zostanie zatwierdzone zatwierdzenie. Ale zauważ, że jest podwójne sprawdzenie: adres URL i rewizja w pobliżu podpisu są porównywane ze strukturami danych w katalogu .git/svn/refs i jeśli adres URL i wersja są z nimi sprzeczne (co jest prawdziwe w przypadku ponownego zatwierdzania zatwierdzeń, ponieważ baza rebase nie dotyka tych struktur), nie jest to brane pod uwagę. Zatem stary URL oddziału był pierwszym adresem URL zatwierdzenia, który nie został ponownie utworzony.

Jeśli chcesz uzyskać czystą wersję Git, możesz wypróbować SubGit jako zamiennik git-svn. Od 2.0 pozwala na utworzenie zapisywalnego, czystego lustra Git z twojego repozytorium SVN, dbając o synchronizację i współbieżność. Uruchom

$ subgit configure --svn-url <SVNURL> project.git 
$ #adjust projectX.git/subgit/{config,authors.txt,passwd} 
$ subgit install project.git 
$ git clone project.git project/ 

Po instalacji możesz go użyć jako zwykłego repozytorium Git.Więc dla ciebie przykład uruchomić:

$ git checkout new_release 
$ git rebase old_release 
$ git push origin new_release 
+0

subgit wygląda bardzo ładnie, niestety jest mało prawdopodobne, że mogę go zainstalować na naszym serwerze SVN, zbyt wielu ludzi na nim polegać i byłoby zrozumiałe awersję do instalowania że gdy rzeczy są w dużej mierze "pracujący". Jak powinienem zrobić to, co próbowałem zrobić w git-svn? – ashgromnies

+1

można zainstalować subgit tylko na komputerze użytkownika i podać --svn-url , tj. Ma prawie takie same wymagania jak git-svn. Z git-svn ... Myślę, że mógłbyś 1) wymeldować się new_release 2) upewnij się, że HEAD ma komunikat commit z poprawnym adresem URL w git-svn-id (np. URL new_release) 3) i cherry-pick zatwierdza jedno- przy pierwszym usuwaniu git-svn-id: sygnatury (np. użyj komendy "git cherry-pick -n" i edytuj komunikaty przed zatwierdzeniem) lub zmień i usuń je po wszystkim za pomocą komendy "git filter-branch". Szczerze mówiąc, nie jestem pewien, czy usunięcie sygnatur git-svn-id jest konieczne, ale lepiej je usunąć. –